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1  Introduction 

For  the  past  several  years,  radar  technology  development  has  focused  on  phased  array 
radars  of  many  types.  These  radars  lend  themselves  to  multi-purpose,  multi-function 
uses  and  to  automatic  control  of  their  modes  of  operation  and  parameters.  Tradition¬ 
ally,  these  mechanisms  have  been  implemented  through  pre-programmed  or  template 
control. 

In  parallel  with  phased  array  radar  developments,  work  has  been  done  in  the  field  of 
artificial  intelligence  (A I).  AI  is  a  branch  of  computer  science  concerned  with  model¬ 
ing  human  intelligence  and  exploiting  such  models  within  a  computer  environment  to 
obtain  useful  information.  A!  is  particularly  effective  when  knowledge  is  incomplete, 
uncertain,  and/or  based  on  heuristics.  Expert  systems  is  a  subfield  of  AI  in  which 
knowledge  or  expertise  is  captured  in  the  form  of  facts  and  rule.s,  and  an  inference 
component  deduces  conclusions  from  these  .facts  and  rules. 

Lately,  there  is  growing  interest  in  applying  AI  technology  to  adaptive  radar  control. 
Using  information  assessed  from  a  radar  environment  to  control  radar  parameters 
and  mode  of  operation  requires  judgement  and  heuristics  that  can  be  more  easily 
embodied  in  rules  than  in  algorithms.  Moreover,  the  dynamic  environment  and  the 
need  for  rapid  control  decisions  require  automated  computer  support  that  can  best 
be  provided  by  an  expert  system. 

An  earlier  Rome  Laboratory  project,  Adaptive  Control  for  Multi-Domain  Sensor 
Processor  (ACMDSP,  Contract  F30602-86-C-0204),  applied  AI  and  expert  system 
technology  to  automating  adaptive  radar  control  within  a  simulated  surveillance  en¬ 
vironment.  The  system  was  intended  to  be  used  in  a  laboratory  environment  as  a 
demonstration  and  development  tool,  and  is  documented  in  Adaptive  Controller  for 
Multi- Domain  Sensor  Processors,  dated  September  1988. 

This  contract.  Integrated  Multi-Domain  Radar  Demonstration  (IMRD),  combines  AI 
and  state-of-the-art  experimental  radar  technology  within  a  real,  as  opposed  to  a 
hypothetical,  radar  environnient.  Its  major  objectives  include  real-time  performance, 
a  framework  for  rulebase  evolution,  end-product  flexibility  for  migration  to  other 
hardware  environments,  and  effective  use  of  existing  resources. 

In  the  resulting  testbed,  artificial  inteCigence  is  embedded  in  an  adaptive  control 
expert  system  which  identifies  interference  in  radar  returns  and  recommends  the  ap¬ 
propriate  responses  to  be  implemented  during  the  next  scan.  Categories  of  identified 
interference  include  ground  clutter,  weather  clutter,  and  jammers.  Jammers  are  dis¬ 
criminated  by  wideband  or  narrowband,  by  pulse  or  continuous,  and  by  mainlobe 
or  sidelobe.  Countermeasur<s  include  frequency  changes,  sidelobe  blanking,  sidelobe 
cancelling,  polarization  changes,  and  adaptive  moving  target  indicator  (MTI).  Ad- 
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ditionally,  the  surveillance  region  can  be  partitioned  into  threat  zones  prioritized  by 
the  importance  of  maintaining  detection  within  them.  Antenna  beam  dwell  time  is 
allocated  to  the  different  regions  so  as  to  achieve  the  highest  probabilities  of  target 
detection  in  the  highest  threat  regions. 

Chapter  2  of  this  report  is  an  executive  summary.  The  remaining  chapters  present  the 
system  design  and  development  (Chapter  3),  the  resulting  demonstration  (Chapter 
4),  and  our  conclusions  and  recommendations  (Chapter  5).  Appendices  document 
specific  system  features. 

Specific  instructions  for  system  configuration  and  use  are  contained  in  the  User  Man¬ 
ual  for  Integrated  Multi-Domain  Radar  Demonstration  [UM]  dated  May  30,  1991. 
The  Test  Plan  and  Procedures  for  Integrated  Multi-Domain  Radar  Demonstration 
[TP],  April  17,  1991,  documents  the  tests  performed  during  the  final  system  demon¬ 
stration. 
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2  Executive  Summary 

The  objective  of  the  IMRD  program  is  to  apply  artihcia)  intelligence  techniques  to 
the  adaptive  control  of  a  state-of-the-art  radar  environment.  The  radar  operates  in 
the  C-Band  and  is  located  within  the  Rome  Laboratory  Surveillance  Facility  (RLSF), 
Building  106,  Griffiss  Air  Force  Base  (GAFB).  The  artificial  intelligence  is  embedded 
in  an  adaptive  control  expert  system  which  is  written  in  Prolog. 

This  system  identifies  sources  of  interference  in  each  antenna  beam  position  of  the 
surveillance  region  and  responds  with  the  appropriate  adaptive  controls  to  maximize 
the  probability  of  target  detection  consistent  with  operator-specified  tactical  objec¬ 
tives.  In  addition,  the  system  has  the  following  features: 

1.  Radar  inputs  provided  by  a  real,  as  opposed  to  a  simulated,  radar. 

2.  Real-time  operation  with  one  scan  response  time  of  ten  seconds  or  less. 

3.  Modular  design  for  rulebase  and  system  evolution. 

4.  Extensive  parameterization  for  different  radar  configurations  and  operational 
specifications. 

5.  Control  of  a  large  number  of  radar  parameters. 

The  following  sections  review  the  top-level  IMRD  organization,  parameterization  op¬ 
tions  for  configuring  it  to  different  environments,  the  expert  system  software  devel¬ 
opment,  and  our  results. 

2.1  IMRD  Organization 

The  IMRD  block  diagram  is  shown  in  Figure  2-1.  It  can  be  conceptually  divided  into 
five  major  subsystems,  all  operating  in  real-time: 

1.  C-Band  radar  and  related  equipment. 

2.  Environmental  signal  processing  (ESP),  which  resides  on  a  Star  Technologies 
ST- 100  array  processor. 

3.  Detection  signal  processing  (DSP)  including  moving  target  indicator  (MTI), 
and  continuous  false  alarm  rate  (CFAR)  processing,  which  provides  video  to  a 
UPA-62  PPI  display. 


B''igure  2-1:  IMRD  Block  Diagram 


4.  An  Adaptive  Controller,  which  resides  on  a  Digital  Equipment  Corporation 
VAX  8650. 

5.  A  Radar  Controller,  which  resides  on  a  Hewlett  Packard  HP2117. 


The  C-Band  radar  processes  consecutive  beams  in  a  scan  region  of  up  to  90“  in  az¬ 
imuth.  Azimuth  range  and  number  of  be2uns  are  among  the  user-supplied  parameters. 
The  top  part  of  Figure  2-2  illustrates  a  typical  surveillance  region  containing  40  beams 
over  45“  in  azimuth. 

The  radar  is  step-scanned  over  the  azimuth  range  of  90“  with  variable  dwell  time  per 
beam  (apportioned  by  the  Adaptive  Controller  so  that  the  total  scan  time  is  within  a 
user-specified  constraint,  nominally  set  to  ten  seconds).  As  indicated  in  the  bottom 
of  Figure  2-2,  the  waveform  for  each  beam  dwell  is  divided  into  three  processing 
intervals: 
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Figure  2-2:  Real-Time  Scan  Timeline 
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1.  A  passive  listening  interval,  designated  Coherent  Processing  Interval  1  (CPU), 
for  detecting  jammers  and  radio  frequency  interferenc-e  (RFI)  sources. 

2.  An  active  environmental  assessment  interval,  designated  Coherent  Processing 
Interval  2  (CPI2),  for  detecting  ground  clutter  and  weather. 

3.  An  adaptive  target  detection  waveform,  designated  Coherent  Processing  Inter¬ 
val  3  (CPI3),  with  appropriate  electronic  counter-counter  measures  (ECCM) 
enabled,  as  determined  by  the  expert  system. 

CPU  and  CPI2  are  passed  to  the  ST-100  array  processor  which  averages  the  passive 
dwell  data  to  enable  jammer  detection  and  calculates  the  jammer  frequency  spec¬ 
trum  to  enable  bandwidth  assessment.  For  the  active  dwell,  the  ST-100  finds  the 
range/doppler  characteristics  via  a  doppler  filter  bank  to  detect  ground  and  weather 
clutter.  The  range-doppler  surface  has  900  range  cells  and  16  doppler  bins  for  a  to¬ 
tal  of  14,400  measurements  per  beam  position.  CPI3  is  sent  through  the  real-time 
detection  signal  hardware  to  a  UPA-62  PPI  for  display. 

The  results  of  ST-100  processing  are  passed  as  Beam  Scan  Data  inputs  to  the  Adaptive 
Controller  expert  system  which  is  written  in  Prolog  and  resides  on  the  VAX  8650. 
The  Adaptive  Controller  analyzes  these  data  for  sources  of  interference,  determines 
what  control  changes  should  be  made  during  the  next  scan  to  maximize  probability 
of  target  detection  in  conjunction  with  prioritized  regions  of  coverage,  and  sends  the 
resulting  Radar  Control  Parameters  to  the  radar  via  the  HP2117  Radar  Controller. 

The  Adaptive  Controller  can  also  interface  with  a  Flexible  Radar  Data  Executive 
(FRDE)  for  stand-alone  testing  and  demonstration.  The  FRDE  software  resides  on 
the  VAX  and  is  spawned  as  a  process  by  the  Adaptive  Controller  when  the  user 
selects  this  option.  In  this  case,  the  FRDE  sends  stored  radar  data  to  the  Adaptive 
Controller  and  retrieves  Adaptive  Controller  outputs,  displaying  them  and/or  saving 
them  in  a  file. 

Radar  control  software  resides  on  an  HP2117  computer.  Expert  system  outputs  are 
sent  from  the  VAX  to  the  HP2117.  The  latter  converts  them  to  hardware  commands 
and  controls  the  waveform  timing  and  signal  processing  for  the  next  scan. 

Table  1  lists  the  the  RLSF  equipment  used  to  implement  the  functions  of  Figure  2-1, 
the  specific  interference  identified,  and  adaptive  controls  applied.  Figure  2-3  shows 
the  hardware/software  configuration. 

2.2  Parameterization 

The  adaptive  control  software  can  be  configured  for  a  wide  variety  of  radar  hardware 
environments  and  user  tactical  objectives  Table  2  summarizes  the  parameters  which 
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Figure  2-3:  Hardware/Software  Configuration 
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Subsystem 

RLSF  Implementation 

Radar  system 

C-Band 

Adaptive  control  host  computer 

VAX  8650 

Adaptive  control  software 

Prolog  driver  with  Pascal  procedure 
calls  and  spawned  FORTRAN  in¬ 
terface  processes.  Expert  system 
rules  in  Prolog;  computation  and 
data  structures  in  Pciscal. 

Environmental  assessment  signal 
processing  host  computer 

ST- 100 

Radar  control  host  computer 

HP2117 

Detection  display 

UPA-62  PPI 

AI  display 

VTIOO  type  terminal 

Waveform  parameters 

•  PRI 

•  Bandwidth 

•  Pulse  duration 

•  Pulse  coding 

•  Doppler  resolution 

•  Spatial  resolution 

•  Polarization 

3.0  msecs 

1.0  MHz 

16  fisecs 

LEM 

25  HZ 

1°  azimuth  by  150m  range 

Matched  or  orthogonal  linear  polar¬ 
izations  with  provision  for  circular 

Interference  identified 

•  Jammers: 

-  Narrowband/wideband 

-  Mainlobe/sidelobe 

-  CW /asynchronous  pulsed 

•  Ground  clutter 

•  Weather  clutter 

Radar  controls 

•  Sidelobe  blanking  on/off 

•  Transmit  polarization 

•  Frequency  hopping 

•  Variable  MTI  weights 

•  Variable  beam  dwell  time 

•  Sidelobe  cancelling  on/off 

Table  1:  RLSF'  Implementation 
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are  selected  by  the  user  through  a  file  or  interactive  entry.  The  Radar  Design  Pa¬ 
rameters  and  Radar  Environment  Parameters  are  specific  to  RLSF  C-Band  testbed 
and  would  be  changed  only  to  accommodate  a  different  hardware  environment.  The 
remaining  parameters  allow  the  user  to  set  adaptive  control  objectives  and  output. 


2.3  Expert  System  Software  Development 

The  Adaptive  Controller  expert  system  uses  Beam  Scan  Data  inputs  from  one  .scan  to 
select  Radar  Control  Parameters  for  the  next  scan.  Figure  2-4  illustrates  the  software 
modules  that  support  this  process; 

1.  A  User  Interface  allows  the  user  to  specify  default  input  parameters  or  to  enter 
the  parameters  interactively. 

2.  An  AI  Engine  assesses  the  current  environment  and  selects  radar  control  op¬ 
tions  for  the  next  scan. 

3.  An  AI  Display  displays  user-selected  parameters  on  the  screen  and/or  saves 
them  in  a  file. 

Figure  2-5  shows  a  breakdown  of  the  AI  Engine  subproblems:  ID  Passive  Interference, 
ID  Active  Interference,  Determine  Applicable  ECCM,  and  Allocate  Radar  Resources. 

ID  Passive  Interference  uses  CPU  passive  dwell  data  to  detect  CW  and  asyn¬ 
chronous  pulsed  (ASP)  jammers.  If  a  jammer  is  found,  the  peak  jammer-to-noise 
ratio  (JNR),  jammer  range,  and  mainlobe  duty  factor  are  reported. 

ID  Active  Interference  uses  CPI2  active  dwell  data  to  detect  weather  and  ground 
clutter.  If  active  interference  is  identified,  the  peak  clutter-to-noise  ratio  (CNR),  the 
maximum  range  of  the  clutter,  and  the  doppler  extent  of  the  clutter  are  reported. 

Determine  Applicable  ECCM  analyzes  the  interference  identifications  and  selects 
appropriate  ECCM,  ranking  plans  that  counteract  the  interference  by  increasing  prob¬ 
abilities  of  target  detection. 

Allocate  Radar  Resources  uses  the  plans  developed  by  Determine  Applicable  ECCM 
along  with  user-assigned  Priority  Zones  and  Quality  Options  Tables  to  select  the  best 
operating  plan  for  the  next  scan  that  meets  a  user-specified  scan  time. 

The  Adaptive  Controller  contains  approximately  10,000  lines  of  code  written  in  Pro¬ 
log,  with  Pciscal  procedure  calls  and  spawned  FORTRAN  processes.  Prolog  is  used 
for  the  main  driver,  rulebases,  and  expert  system  inferencing.  Pascal  is  used  for  com¬ 
putation  and  data  structures.  VAX,  HP2117,  and  the  stand-alone  FRDE  processes 
are  written  in  FORTRAN. 
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Type 

Description 

B.adar  Design  Parameters 

Defines  physical  characteristics  c  the  radar,  de¬ 
sired  detection  range,  desired  target  cross  section 

Radar  Environment  Parameters 

Thermal  noise,  ground  and  weather  clutter  maps* 
used  for  interference  identification 

Initial  Radar  Control  Parameters 

Radar  Control  Parameter  settings  for  the  first 
scan 

Priority  Zones 

Divides  scan  region  into  zones,  based  on  the  im¬ 
portance  of  maintaining  detection  within  them 

Quality  Option  Plans 

Operating  plans  used  to  allocate  beam  dwell  time 
by  Priority  Zones 

AI  Control  Parameters 

•  Desired  Scan  Time 

Maximum  time  allowed  per  scan 

t  AI  On 

Selects  full  adaptive  control  or  interference  iden¬ 
tification  only 

•  ECCM  Usage 

Selects  which  ECCMs  are  available  in  a  given 
radar  system 

•  Quality  Option  Selection 

Allows  automatic  override  of  AI  Quality  Option 
Plan  selection,  regardless  of  scan  time  constraints 

•  Configuration  Selection 

Selects  radar  interface  (live  data)  or  stand-alone 
(taped  data)  software  configuration 

AI  Output  Parameters 

Selects  parameters  displayed  on  the  VTIOO  or 
stored  in  a  file 

*  Boolean  maps  that  specify  regions  in  range/doppler  where  clutter  is  expected. 

Table  2:  User- Selectable  Parameters 
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Figure  2-4:  Adaptive  Controller  Configuration 
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Prolog  has  been  especially  conveni>?nt  for  system  development:  the  similarities  be¬ 
tween  Prolog  predicates  and  English  rules  make  the  expert  system  visible  for  rule-^ 
base  formulation  and  evolution;  its  built-in  logic  handles  rulebase  irifermcing  trans¬ 
parently;  it  supports  foreign  language  interfaces  well  for  incorporating  code  in  other 
languages. 

2.4  Demonstration  and  Training 

Formal  demonstration  and  training  were  held  on  April  17  and  18,  1991.  The  following 
capabilities  were  demonstrated: 

1.  Identification  of  single  and  multiple  sources  of  interference  in  the  radar  data. 

2.  Control  of  radar  parameters  including  frequency,  sidelobe  blanking,  si  delobe 
cancelling,^  polarization,  and  MTI  weights. 

3.  Differential  allocations  of  dwell  time  based  on  user-specified  priority  zones  and 
scan  times. 

4.  Observation  of  targets  of  opportunity,  as  available,  and  simulated  targets  in¬ 
jected  into  the  display. 

5.  Performance  within  the  government- specified  ten  second  scan  time. 

Training  consisted  of  demonstrating  how  to  set-up  the  radar,  how  to  to  initialize  the 
various  computer  systems,  and  how  to  run  the  software.  In  addition,  users  had  the 
opportunity  to  input  and  modify  various  policy  control  parameters  while  the  radar 
was  running.  The  convenient  menus  enabled  new  ers  to  modify  parameters  with 
little  assistance  or  training. 

2.5  Summary 

This  contract  has  successfully  applied  artificial  intelligenct  to  adaptive  rado^  '’ontrol. 
The  resulting  IMRD  hardware/software  configuration  operates  in  real-t  in  the 
presence  of  multiple  sources  of  interference,  resulting  in  observable  improvements  in 
target  detection. 

We  have  provided  the  government  with  an  AI  testbed  and  performance  benchmark 
for  continued  adaptive  control  development.  IMRD  modular  design,  combined  with 

’Although  SLC  equipment  was  unavailable  for  the  tests,  the  Adaptive  Controller  selected  this 
option  when  appropriate  and  printed  a  message  to  this  effect. 
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extensive  parameterization,  supports  rulebase  evolution  and  tailoring  the  adaptive 
control  software  to  other  hardware  environments.  Comprehensive  hardware  and  soft¬ 
ware  documentation  will  facilitate  this  continued  development. 


15 


3  System  Design  and  Development 

Figure  2-1  shows  the  high-level  functionality  of  an  adaptive  control  radar  system 
and  the  resulting  RLSF  implementation.  The  major  components  are  the  radar,  sig¬ 
nal  processing,  adaptive  control,  display,  and  radar  control.  The  radar  transmits  a 
waveforrr  and  receives  returns  in  which  targets  may  be  obscured  by  different  sources 
of  interference.  Signal  processing  includes  real-time  processing  necessary  for  display 
of  the  radar  returns  (DSP)  as  well  as  spatial  and  spectral  analysis  of  data  sent  to 
the  Adaptive  Controller  for  ascertaining  interference  (ESP).  The  Adaptive  Controller 
identifies  sources  of  interference  in  the  processed  data  and  selects  control  changes  for 
the  next  scan.  The  Radar  Controller  implements  the  recommended  changes. 

We  conducted  a  series  of  tradeoff  studies  to  assess  available  hardware  and  software, 
and  to  propose  an  implementation  for  this  basic  configuraticn.  Alternate  RLSF  archi¬ 
tectures  were  evaluated  with  respect  to  their  capabilities  for  satisfying  the  following 
demonstration  goals: 

1.  Use  available  equipment  for  all  functions  except  possibly  for  minor  modifications 
to  equipment  interfaces. 

2.  Select  an  approach  with  low  enough  risk  to  ensure  a  high  probability  of  success, 
but  that  would  still  allow  a  wide  range  of  experiments. 

3.  Maximize  processing  speed  within  the  constraints  of  available  equipment  to 
effect  a  real-time  demonstration. 

4.  Control  a  sufficient  number  of  radar  parameters  with  the  Adaptive  Controller 
for  a  credible  demonstration. 

5.  Establish  performance  and  evaluation  criteria. 

Specific  concerns  in  implementing  the  system  architecture  are  discus.sed  in  the  follow¬ 
ing  paragraphs.  They  include: 

1.  How  best  to  incorporate  the  A I  adaptive  control  simulation  performed  on  a 
previous  Rome  Laboratory  contract. 

2.  The  choice  of  L-  versus  C-Band  radar. 

3.  Signal  processing  features,  platform,  and  implementation. 

4.  Adaptive  control  features,  platform,  and  implementation. 

5.  Radar  control  platform  and  implementation. 

6.  Display  features  and  implementation. 
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3.1  Survey  of  Existing  Resources 

3.1.1  ACMDSP  Simulation 

One  of  the  first  tasks  of  the  contract  was  to  evaluate  the  applicability  of  the  ACMDSP 
simulation  (Contract  F30602-86-C-0204)  for  incorporation  into  the  AI  testbed.  This 
section  gives  the  conclusions  of  this  evaluation  at  a  summary  level.  Additional  de¬ 
tails  regarding  ACMDSP  applicability  are  in  the  Interim  Report  for  Integrated  Multi- 
Domain  Radar  Demonstration  [IR],  August  31,  1989,  pages  5-16. 

The  ACMDSP,  developed  under  a  prior  Rome  Labs  contract,  simulates  a  tactical 
radar  environment  and  performs  adaptive  control  on  the  resulting  data.  The  radar  is 
specified  by  operator  inputs  such  as  coverage,  maximum  instrumented  range,  azimuth 
beam  width,  elevation  beam  width,  scan  time,  frequency,  target  cross  section,  and 
available  ECCM.  Operator-selected  target  amd  interference  characteristics  are  used 
to  generate  the  radar  data  that  would  be  produced  by  the  hypothetical  environment. 
These  data  are  analyzed  for  sources  of  interference,  and  the  simulated  radar  operation 
is  modified  in  the  next  scan  to  maximize  detection  range  in  the  presence  of  that 
interference. 

The  ACMDSP  main  software  components  are  a  Radar  Model  that  simulates  the  radar 
environment  and  aircraft  targets,  and  an  Adaptive  Controller  that  processes  the  radar 
data  for  a  scan  and  determines  the  operating  plan  for  the  next  scan.  Figure  3-1, 
taken  from  the  ACMDSP  Final  Report  [ACMDSP],  shows  this  organization  and  the 
major  program  inputs.  Communication  between  the  Radar  Model  and  the  Adaptive 
Controller  is  through  the  VAX/VMS  mailboxes.  The  Adaptive  Controller  is  written 
in  Prolog,  and  interfaces  to  routines  written  in  Pascal  which  is  used  for  data  structure 
implementation,  mailbox  utilities,  and  computation. 

At  the  start  of  this  contract,  Digicomp/Sensis  had  hoped  to  transfer  the  ACMDSP 
Adaptive  Controller  to  the  RLSF  with  minor  changes  to  the  content  of  the  scan  data 
inputs  and  the  control  parameter  outputs.  The  Radar  Model  would  be  replaced  by 
RLSF  equipment,  and  the  VMS  mailboxes  would  be  maintained  for  conununication 
between  Adaptive  Controller  and  RLSF  hardware.  The  Radar  Model  would  be  modi¬ 
fied  as  necessary  to  reflect  discrepancies  with  the  real  radar,  and  a  Radar  Parameters 
File  would  be  generated  with  the  RLSF  C-Band  characteristics.  The  Radar  Model 
could  then  simulate  the  real  environment  for  testing  the  IMRD  Adaptive  Controller 
or  for  evaluating  new  adaptive  control  policies,  and  could  be  used  as  a  demonstration 
when  operating  the  real  radar  was  infeasible. 

However,  we  found  that  the  ACMDSP  was  not  as  straightforward  to  transfer  as  we 
had  hoped.  The  Radar  Model  does  not  prcwide  a  true  simulation  since  it  produces 
the  measured  values  of  interference  parameters  as  opposed  to  the  signals  themselves. 
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Figure  3-1:  ACMDSP  System  Block  Diagram 

Moreover,  substantial  changes  were  needed  in  its  adaptive  control  expertise  (as  dis¬ 
cussed  in  [IR]).  For  example,  all  non-zero  doppler  data  in  the  ACMDSP  is  aggregated 
into  a  single  number  with  januner  and  clutter  determinations  based  on  comparison  be¬ 
tween  zero  and  non-zero  components;  we  found  it  necessary  to  use  unaggregated  data 
from  the  entire  spectrum  to  identify  interference.  Moreover,  neither  signal  processing 
assumptions  nor  inputs  to  and  outputs  from  the  simulated  radar  are  compatible  with 
what  would  be  generated  in  the  RLSF  radar  environment.  For  example,  we  deter¬ 
mined  that  a  single  waveform  would  be  insufficient  for  identifying  interference  such 
as  jammers  and  clutter  and  for  detecting  targets  with  an  adapted  waveform. 

Despite  these  findings,  the  ACMDSP  was  a  good  stating  point  for  the  IMRD  effort. 
Much  of  the  design  and  some  of  the  data  structures  were  directly  reusable.  Those 
that  were  not  provided  a  good  first  approximation.  Many  of  the  code  modules — in 
particular,  mailbox  utilities — were  reuseable.  The  Prolog/Pascal  coordination  was 
adopted,  combining  the  best  features  of  both  languages:  Prolog  for  AI  inferencing 
and  Pascal  for  data  structures,  mailbox  utilities,  and  computation. 
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3.1.2  L-  Versus  C-Band  Radar 

The  contract  statement  of  work  (SOW)  allowed  for  the  use  of  either  the  L-  or  C-Band 
system  for  IMRD  demo.  A  review  of  RLSF  resources  was  conducted  and  various 
equipment  conhgurations  were  evaluated  to  determine  which  L-  or  C-Band  radar 
parameters  were  controllable  as  a  result  of  adaptive  control  decisions,  and,  on  this 
basis,  to  select  one  for  IMRD  development. 

Since  the  L-  and  C-Band  RLSF  radars  share  the  same  processing  equipment,  both 
systems  have  essentially  the  same  capability  for  signal  processing,  environmental  as¬ 
sessment,  and  AI  decisions.  The  major  differences  are  in  the  degree  to  which  each 
radar  r.an  be  controlled.  Table  3  assesses  the  control  capabilities  of  each  system  as  was 
projected  for  late  1989,  with  respect  to  key  experimental  objectives.  For  each  compar¬ 
ison,  the  system  we  considered  most  capable  of  meeting  the  objective  is  highlighted 
in  bold  text. 

The  table  shows  that,  for  this  application,  the  C-Band  radar  offers  substantial  ad¬ 
vantages  over  the  L-Band  system,  in  many  areas,  primarily  due  to  its  phase  steering 
capability,  provision  for  adaptive  mainlobe/sidelobe  cancellation,  adaptive  polariza¬ 
tion  capability,  and  the  existence  of  GFE  (government  furnished  equipment)  jammer 
sources.  One  projected  deficiency  of  the  C-Band  system,  limited  range  processing, 
was  later  eliminated  by  using  a  direct  interval  frequency  all-range  interface  to  the 
signal  processing  equipment  see  Section  3.2).  The  limited  elevation  coverage  of  the 
C-Band  antenna  was  initially  a  concern,  but  later  experiments  verified  that  a  reason¬ 
able  number  of  targets  of  opportunity  could  be  observed  near  the  radar  horizon. 

The  projected  advantage-indicated  in  the  table-of  the  C-Band  radar  with  respect 
to  sidelobe  blanking  proved  to  be  less  than  expected.  Initially,  we  projected  that 
the  weather  blanker  could  be  converted  to  a  sidelobe  blanker  (SLB)  with  only  minor 
modifications.  However,  as  SLB  development  progressed,  the  design  evolved  into 
a  completely  new  circuit  independent  from  the  weather  blanker,  and  the  weather 
blanker  was  returned  to  its  original  conflguration. 

Therefore,  the  results  of  the  tradeoff  indicated  that  a  meaningful  demonstration  could 
be  conducted  with  C-Band  radar  by  configuring  the  experiment  as  follows: 

1.  Configure  the  C-Band  system  for  adaptive  control  of  the  sidelobe  blanker,  side¬ 
lobe  canceller,  RF  frequency,  polarization,  MTI  (using  the  progranunable  trans¬ 
verse  filter),  and  energy  per  beam  (dwell  time). 

2.  Operate  the  radar  over  an  azimuth  surveillance  volume  cornraensurate  with  full 
beam  adaptability  with  electronic  azimuth  steering.  The  azimuth  coverage  will 
be  up  to  ±45  degrees,  the  electronic  scan  iimit  of  the  C-Band  antenna. 
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3.  Allow  some  dead  time  (with  the  radaj  transmitter  disabled)  between  beam 
positions  (i.e.,  beam  dwells)  to  enable  the  synthesizer,  waveform  gentirator,  and 
other  RLSF  equipment  to  receive  the  programmable  parameters  for  the  next 
beam  dwell  tirHCi  llO  enable  enough  time  to  process  the  data  received  during  each 
beam  dwell. 


Objective 

L-Dand 

C-Band 

Support  demonstrations  using 
far-field  jammer  equipment 

RADCSL  bas  no  operating  far- 
field  L-Band  jammer  sources  that 
can  be  remotely  controlled 

Has  two  remotely-controlled 
far-field  jammer  sources 
(controllable  from  HP-2117) 

Controllable  transmit  and  receive 
polarisation 

No 

Required  a  circuit  to  form  re¬ 
ceive  polarization 

Beam  to  beam  dwell  time  vari¬ 
ability 

Not  at  present  (1989) 

Yes,  via  DCU  interface  aird 
electronic  steering 

Capable  of  skipping  beam  posi¬ 
tions  if  nu  target  detected  on  last 
scan 

Not  at  present  (1989) 

Yes,  via  DCU  interface  and 
electronic  steering 

Comp-controllable  scan  time 

Not  at  present  (1989) 

Yea 

Variable  transmit  peak  power 

No  (TWT) 

No  (TWT) 

Variable  transmit  average  power 

Yes,  (limited  by  tolerance  of 
TX  to  varying  load) 

Yes,  (limited  by  tolerance  of 
TX  to  varying  load) 

All  range  processing 

Yes 

Has  buifer/mux  that  limits  range 
extent.  Can  be  achieved  by  step¬ 
ping  range  window  on  consecu¬ 
tive  scans. 

360  degree  azimuth  coverage 

Yes 

Yes,  although  up  to  90  de¬ 
grees  electronic  steering  rec¬ 
ommended  for  demonstra¬ 
tion 

Elevation  coverage 

Fixed  cosecant  squared 

2  degree  beam  with  limited  ele- 
vaticn  mech  scan  capability  lim¬ 
its  chances  of  seeing  targets  of  op¬ 
portunity 

Capability  for  frequency  variabil¬ 
ity 

Limited  to  about  30  MHz  by 
PTS  sythesizer.  Changeable  from 
beam  dwell  to  beam  dwell  with 
sufficient  dead  time  for  synthe¬ 
sizer  lockup 

Approx  300  MHz  changeable 
from  beam  dweU  to  beam 
dwell  with  loss  than  15  psec 
synthesizer  lockup  time  (an¬ 
tenna  limits  #  freqs  to  8) 

Table  3:  Tradeoffs  of  Existing  RLSF  L-Band  and  C-Band  Equipment 
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Objective 

L-Band 

“ 

C-Band 

Range  resolution 

Up  to  20  MHz  instantaneous 
bandwidth 

Up  to  10  MHz  instantaneous 
bandwidth 

Capable  of  mainlobe  antenna 
nulling 

No 

Yes,  using  subarray  outputs 
with  SPARC/DBF  equip¬ 
ment  (*  equipment  not  then  op¬ 
erational) 

Capable  of  sidelobe  antenna 
nulling 

Yes,  (Hazeltine  adaptive 
loops) 

Yes,  via  SPARC/DBF  equip¬ 
ment  using  subarray  outputs 
(jammers  must  be  within 
beamwidth  of  subarrays)* 

ChMgeable  PRF,  number  of 
pulses,  and  pulse  duration  from 
burst  to  burst 

Yes 

Yes** 

Changeable  doppler  filtering 

Yes,  (Signal  processing  in 
PTF) 

Yes,  (Sig  proc  in  PTF) 

TVack  capability  for  up  to  10  tar¬ 
gets  per  scan 

Only  if  new  track-while-scan 
mods  are  implemented 

Only  if  new  track-while-scan 
mods  are  implemented 

Sidelobe  blanker 

No 

Yes,  (weather  radfur  blanker 
in  receiver  string)*** 

Real-time  operation 

E>ead  time  must  be  allowed  be¬ 
tween  beam  positions  to  update 
equipment  parameters  and  per¬ 
form  processing. 

Same  as  L-Band 

Noncoherent  integration 

Yes,  via  PPI  persistence 

Yes,  via  PPI  persistence 

Variable  bandwidth 

Yes,  (dwell  to  dwell) 

Yes,  (dwell  to  dwell) 

Some  hardware  modifications  required. 


**  It  was  subsequently  determined  that  PRF  and  pulse  duration  changes  precluded  real¬ 
time  operation  with  available  equipment  and  risked  transmitter  damage. 

***  Subsequently,  a  new  blanking  circuit  was  developed  and  the  weather  blanker  was  re¬ 
turned  to  its  original  state. 


Table  3:  Tradeoffs  of  Existing  RLSF  L-Band  and  C-Band  Equipment  (Cont’d) 
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3.2  Signal  Processing 

3.2.1  Requirements 

The  AI  testbed  requires  two  types  of  real-time  signal  processing 

1.  ESP  of  special  predetermined  waveforms  to  assess  the  jamming  and  clutter 
interference  background. 

2.  DSP  for  extracting  and  displaying  target  reports  in  the  raw  data. 

This  functional  distinction  does  not  necessarily  imply  that  separate  equipment  is  re¬ 
quired  for  each;  indeed,  one  of  the  major  tradeoffs  v/as  to  decide  whether  available 
throughput  capabilities  and  interfaces  were  sufficient  for  real-time  operation  using 
a  common  processor  (e.g.,  the  ST-100)  for  both.  A  single  processor  could  exploit 
commonality  of  requirements  via  sharing  functions,  resulting  in  an  overall  simplifica¬ 
tion  of  the  processing.  However,  this  advantage  is  outweighed  if  that  processor  hcis 
insufficient  throughput  capacity  for  the  required  processing  in  real-time. 

Therefore,  tradeoffs  were  necessary  to  balance  functional  capabilities  with  implemen¬ 
tation  complexity  and  risk.  Table  4  sununarizes  the  functional  requirements  for  each 
processor,  as  well  as  the  final  configuration  which  evolved  from  these  tradeoffs.  De¬ 
scriptions  of  the  rationale  for  each  table  parameter,  as  well  as  the  individual  tradeoffs, 
are  given  subsequently. 

A  synopsis  of  the  resulting  design,  illustrated  in  Figure  2-3,  is  as  follows: 

1.  ESP  is  performed  by  the  ST-100,  using  its  capability  for  spectral  analysis  of 
radar  data.  A  pre- transmit  passive  dwell  is  used  for  sensing  non-responsive 
jammers.  The  environmental  assessment  measurements  for  clutter  are  based 
on  calculating  the  doppler  filter  bank  output  for  the  coherent  active  dwell  that 
precedes  the  detection  waveform. 

2.  DSP  is  performed  primarily  by  existing  real-time  hardware  to  offload  the  ST- 
100  of  these  functions.  Pulse  compression  is  implemented  by  existing  RLSF 
SAW  compressors.  Clutter  filtering  is  accomplished  by  programming  the  pro- 
graimnable  transversal  filter  (PTF)  processor  as  an  N-piilse  adaptive  MTI  with 
weights  adaptively  determined  for  cancelling  the  clutter  spectrum.  We  initially 
planned  to  use  the  SPARC-DBF  equipment  as  a  real-time  sidelobe  canceller. 
More  detail  pertaining  to  this  design  and  its  evolution  follows. 

3.2.2  Environmental  Signal  Processing 


3.2.2. 1  Design 
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ESP 

DSP 

Consistent  waveform  tailored  to 

Variable  waveform  tailored  adap- 

clutter  and  jammer  measurement 

lively  for  target  detection 

PRF: 

>1  KHz  preferred* 

>  1  KHz  preferred* 

Pulse  Duration: 

Nominally  16  psec 

Nominally  16  psec 

Coding: 

LFM 

LFM 

Bandwidth: 

>1  MHz 

>  1  MHz 

Dwell  Time: 

CPU:  16  PRIs 

CPI2:  16  PRIs 

CPI3:  variable  dwell 

Processing  Required 

Pulse  compression  that  matches 

Pulse  compression  for  increased 

DSP 

radar  range  and  clutter  perfor- 

Doppler  filtering  to  mea- 

mauce 

sure  range-doppler  characteristics 

Adaptive  MTI  or  doppler  filter 

of  clutter 

bank  for  weather  and  groundclut- 

Envelope  and  square  law  detection 

ter  visibility 

for  magnitude  and  power  estima- 

Envelope  detector 

tion  of  interference 

Polarization  adaptivity 

Threshold  detection  to  ascertain 
presence  of  interference 

CFAR  and  threshold 

Spectral  analysis  of  single  PRIs  for 

PPI  display 

ASP  and  CW  jammer  bandwidth 

SLCt 

determination 

Sidelobe  blankers 

Noncoherent  integration  of  magni¬ 
tudes  of  consecutive  range  cells  to 
smooth  measurements 

Estimation  of  whether  jammer  is 
in  antenna  sidelobes  or  mainlobe 

Noncoherent  integration 

Implemented  on 

ST- 100  array  processor,  SAW 

Dedicated  digital  and  analog  GFE 

pulse  compressor,  dedicated  SLB 

hardware 

*  333  HZ  implemented  in  testbed. 

'  Adaptive  control  implemented,  but  equipment  not  available. 


Table  4:  Signal  Processors  Functional  Requirements  and  Design 
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Environmental  assessment  requires  temporal  and  spectral  meausurements  of  the  signal 
in  a  passive  listening  interval  to  identify  jamming.  It  also  requires  measurements  of 
the  range-doppler  characteristics  of  the  radar  return  to  identify  ground  and  weather 
clutter.  A  pre-transmit  passive  dwell,  CPU,  is  used  for  sensing  non-responsive  jam¬ 
mers;  an  active  environmental  assessment  dwell,  CPI2,  is  used  for  measuring  clutter 
characteristics. 

Table  5  gives  an  overview  of  the  waveform  for  each  dwell,  ESP  is  performed  during 
CPIs  1  and  2,  DSP  during  CPIS.  Figures  3-2  and  3-3  show  the  processing  for  CPIs 
1  and  2  in  greater  detail. 


< - One  Beam  Dwell - > 


Environmental  Assessment  Interval 

Detection  Interval 

CPU 

CPI2 

CPIS 

Passive  (Rx  only) 

Active  (Rx  and  Tx) 

Detection  Waveform 

Assess  ECM  without 
clutter  or  targets 

SLC  (SPARC)  calcu¬ 
lates  adaptive 

weights* 

Assess  SLB  %  blank¬ 
ing 

SLC  doesn’t  apply 
weights  to  data* 

Assess  clutter  with 
consistent  waveform 

SLC  turned  so  as 
not  to  corrupt  clutter 
measurement* 

PPI  is  blanked 

Use  adapted  waveform  de¬ 
termined  from  previous  scan 

All  necessary  ECCM  en¬ 
abled 

Routed  to  signal  processor 
and  PPI  display 

*  Growth  capability  not  implemented  due  to  SLC  unavailability 

Table  5:  Waveform  Timeline 

For  CPU ,  a  power  computation  is  made  of  the  received  signal  and  sent  to  the  Adaptive 
Controller,  where  a  decision  is  made  as  to  the  presence  of  a  jammer.  The  computation 
is  made  by  segmenting  the  receive  signal  over  eight  pulse  repetition  intervals  (PRIs) 
into  block  integrations  and  reporting  the  output  of  each  block  integrator.  The  Adap¬ 
tive  Controller  then  thresholds  these  voltages  to  ascertain  the  presence  or  absence  of 
a  jammer  signal.  Further  identification  of  the  jammer  is  done  by  calculating  the  peak- 
to-average  ratio  of  this  vector,  as  is  discussed  in  Section  3. 3. 2. 3.  The  bandwidth  of  the 
jammer  is  estimated  via  a  fast  Fourier  transform  (FFT)  of  the  contiguous  range  cells 
of  the  PRI  with  the  highest  duty  factor  discriminating  narrowband  from  wideband 
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jammers.  For  this  application,  the  former  type  of  jammer  occupies  a  small  percentage 
of  the  receive  bandwidth;  the  latter  occupies  at  least  the  full  receive  bandwidth.^ 

For  CPI2,  merisurements  of  the  range-doppler  response  are  made  from  an  active  envi 
ronmental  assessment  waveform  which  is  constant  from  scan  to  scan.  Block  integra¬ 
tors  for  each  of  16  doppler  filters  average  the  received  magnitude  over  32  contiguous 
range  cells  within  30  multiple  contiguous  range  segments.  These  measurements  are 
reported  to  the  Adaptive  Controller,  where  they  are  thresholded  to  detect  and  to 
determine  range  and  doppler  boundaries  for  ground  and  weather  clutter. 

Second  order  statistics  are  computed  for  estimating  interference  power  levels  and  as 
an  indicator  of  the  degree  of  variation  (variability  ratio)  of  the  measured  values  over 
the  block  intervals.  The  variability  ratio,  computed  as  the  ratio  of  the  mean  squared 
to  mean  value  squared,  provides  a  discriminant  which  can  be  used  by  the  AI  rulebase 
to  detect  interference  with  Rayleigh-like  magnitude  statistics  (such  as  weather,  noise 
jamming,  and  R,ayleigh  ground  clutter).  Even  though  the  variability  ratio  is  not 
presently  used,  it  is  calculated  and  cm  be  incorporated  into  future  rules. 

3. 2. 2. 2  Design  Evolution 

The  choice  of  waveform  and  environmental  assessment  processing  was  influenced  by 
the  following: 

Real-time  operation  was  one  of  the  greatest  challenges  of  this  program.  This  was  due 
to  the  volume  of  processing  required  and  the  fact  that  not  all  existing  equipment  (e.g., 
the  VAX)  is  especially  suited  for  real-time  operation.  The  real-time  requirement  had  a 
major  impact  on  the  design  decisions,  driving  the  design  toward  a  multiple-processor 
architecture. 

Maximum  isolation  of  measurements  was  necessary  between  jammer  and  clutter 
sources  to  prevent  complications  in  discriminating  overlapping  interference.  Jam¬ 
mers  are  assessed  with  the  transmitter  off  during  CPU  to  prevent  clutter  and  targets 
from  corrupting  the  measurements.  However,  the  clutter  assessment  interval  (CPI2) 
contains  overlapping  janmier  interference,  hampering  clutter  identification  unless  the 
jammers  are  cancelled.  As  a  result,  clutter  is  identified  after  ECCMs  have  been 
applied  to  a  jammer. 

A  consistent  waveform  with  parameters  tailored  to  clutter  nieasiurements  is  preferable 
to  using  the  variable-parameter  detection  waveform  (CPI3)  for  clutter  measurement. 

^Ideally,  this  measurement  is  made  over  as  large  a  receive  bandwidth  as  possible,  and  preferably 
over  the  entire  radar  agile  bandwidth  for  a  true  wideband  jammer  assessment.  For  the  IMRD 
demo,  the  measurement  bandwidth  was  constrained  to  the  receiver  instantaneous  bandwidth  so  as 
to  remain  within  RLSF  capabilities  and  to  preclude  excessive  cost  for  implementing  an  additional 
wideband  processing  channel.  Nonetheless,  the  bandwidth  is  sufficient  for  proof  of  concept. 


Figure  3-2:  CPU  Processing 


Header  Extract  sidelobe 

- ►  blanker  count _ ^  sideiobe.sum 

from  header 
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Adaptive 

Controller 
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Figure  3-3:  CPI2  Processing 


Depending  on  the  Adaptive  Controller  decisions,  the  latter  will  not  necessarily  be 
proper  for  meaisuring  clutter.  For  example,  in  an  extreme  case,  if  the  Al  controller 
decides  to  skip  a  beam,  the  detection  waveform  may  not  be  transmitted  at  all,  even 
though  a  clutter  measurement  in  that  beam  may  still  be  desired.  CPI2  waveforms  with 
PRFs  greater  than  1  KHz  are  necessary  to  prevent  spectral  foldover  of  measurements 
of  the  weather  clutter  spectral  spread.^  Also,  to  enable  sufficient  accuracy  for  clutter 
bandwidth  estimations,  the  coherent  processing  interval  for  the  doppler  filter  bank 
was  chosen  to  be  at  least  16  psec  (about  2  m/sec  doppler  resolution  at  C-Band).  This 
is  not  necessarily  guaranteed  for  CPI3. 

The  jammer  detection  interval  must  be  long  enough  to  detect  low  PRF  asynchronous 
pulsed  (ASP)  jammers.  For  this  reason,  eight  radar  PRls  were  dedicated  for  detecting 
the  jammer  pulses,  with  a  timeline  which  supports  growth  to  16  PRIs.  In  retrospect, 
16  PRIs  was  probably  overkill  since  radar  timeline  is  impacted  by  being  unable  to 
transmit  in  this  interval.  Finer  tuning  of  the  CPU  dwell  time  and  incorporati;." 
scan-to-scan  history  are  possible  improvements. 

Pulse  compression  is  necessary  for  clutter  measurements  to  provide  similar  sensitivity 
to  the  detection  waveform  (CPI3)  which  likewise  uses  pulse  compression.  It  is  alsu 
necessary  for  achieving  sufficient  clutter-to-noise  (CNR)  ratio  for  clutter  measure¬ 
ment. 

Averaging  measurements  over  contiguous  time  samples  reduces  the  data  that  must 
be  passed  to  the  Adaptive  Controller.  This  reduces  I/O  time,  and  enables  a  more 

^However,  8  subtlety  in  the  PTF  MTI  equipment — which  was  discovered  during  the  integration 
and  test  phase — constrained  the  operating  PRF  for  the  demo  to  be  333  Hz  maximum. 
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accurate  determination  of  power  level  for  each  range-doppler  sample. 

Processing  tradeoffs  for  detecting  weather  were  a  major  consideration.  The  chosen 
approach  involves  doppler  filter  bank  processing  to  derive  range-doppler  character¬ 
istics  of  the  clutter  and  discriminants  based  on  expected  locations  of  the  weather 
in  the  range-doppler  plane.  As  an  added  discriminant-measurement  of  the  clutter 
power  difference  between  two  polarization  channels,  one  matched  to  the  transmit  po¬ 
larization,  the  other  orthogonal  to  it-would  offer  improved  performance.  However, 
equipment  limitations  made  the  polarization  ratio  measurement  impractical. 

GFE  capabilities  were  evaluated  for  all  design  candidates.  These  tended  to  constrain 
variables  such  as  the  maximum  bandwidth,  maximum  PRF,  pulse  coding  for  efficient 
real-time  hardware  pulse  compression,  and  the  amount  of  processing  that  could  be 
implemented  in  real-time. 

3. 2. 2. 3  Equipment  Tradeoffs 

Tradeoff  studies  were  rxinducted  to  determine  the  best  equipment  for  meeting  the 
environmental  assessment  requirements  discussed  in  Section  3. 2. 2.2.  We  considered 
using  existing  digital  processors  within  the  RLSF,  analog  pulse  compression,  a  hard¬ 
ware  sidelobe  jammer  duty  factor  estimator,  and  programmable  signal  processing 
using  either  the  AP-TiO,  ST-100,  HP2117,  or  VAX  computers. 

Doppler  Filter  Bank:  The  requirement  for  a  complete  doppler  filter  bank  implied  a 
programmable  signal  processor  since  none  of  the  existing  real-time  signal  processing 
equipment  could  form  16  simultaneous  doppler  filters  in  real-time.  The  ST- 100  was 
the  clear  choice  of  the  programmable  signal  processor  candidates  because  of  its  supe¬ 
rior  throughput  rate  relative  to  the  others  and  an  available  doppler  filter  applications 
program.  Moreover,  the  other  functions  (shown  in  Figures  3-2  and  3-3)  were  well 
within  the  ST- 100  capabilities  and  many  had  applications  programs  in  development 
at  the  time  of  this  decision. 

Pulse  Compression:  The  two  candidate  solutions  for  pulse  compression  were  to 
implement  a  two-transform  pulse  compressor  with  the  ST- 100  software,  and  to  use 
the  existing  SAW  compressor. 

To  maximize  the  testbed’s  capability  for  real-time  opt:ration,  we  offloaded  this  func¬ 
tion  from  the  ST- 100  to  dedicated  hardware.  This  enabled  more  parallel  processing, 
albeit  with  some  sacrifice  of  waveform  flexibility.^ 

Bandwidth  and  PRF:  As  a  result  of  the  decision  to  use  the  ST- 100,  our  next  con- 

^The  RLSF  SAW  pulse  compressor  is  optimized  for  LFM  waveforms  with  2.5  MHz  bandwidth 
and  40  psec  duration,  although  it  can  compress  other  LFM  waveforms  with  the  ejinie  frequency/time 
slope, 
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sideration  pertained  to  the  maximum  sample  rate  (i.e.,  waveform  bandwidth).  Due 
to  I/O  limitations  of  the  digital  hardware  interface  (DHI),  the  maximum  complex 
word  transfer  rate  into  the  ST-100  is  1  MHz;  to  process  higher  bandwidth  signals, 
an  existing  FIFO  (first  in,  first  out)  can  be  used  to  range  window  the  receive  data, 
slowing  it  down  for  transfer  into  the  processor.  The  FIFO  approach  precludes  “all 
range”  processing  and  incurs  additional  complexity.  Therefore,  we  decided  that  1 
MHz  bandwidth  waveforms  were  sufficient  for  demonstrating  proof  of  concept,  and 
that  the  FIFO  was  not  necessary. 

The  product  of  the  sample  rate  and  PRI  gives  the  number  of  samples  that  needs  to  be 
processed  in  the  unambiguous  range  interval.  Available  ST-100  application  programs 
had  been  successfully  demonstrated  within  the  RLSF  with  up  to  IK  sample  PRIs; 
from  a  risk  management  standpoint,  this  factor  favored  the  choice  of  a  PRI  of  about 
1  msec  (i.e.,  1  KHz  PRF).  The  weather  measurement  function  favors  a  higher  PRF, 
although  a  1  KHz  PRF  was  deemed  marginally  sufficient  for  preventing  spectral 
foldover  for  a  worst-case  weather  spectral  spreaH  at  a  5.7  m/sec-krn  wind  shear. 

Sidelobe  Jammer  Determination:  One  of  the  Adaptive  Controller  functions  is  to 
determine  whether  a  jammer  is  in  the  radar  mainlobe  or  in  the  sidelobes.  For  mainlobe 
jammers,  traditional  sidelobe  cancellers  (SLC)  and  sidelobe  blankers  (SLBs)  offer  no 
improvement.  Therefore,  when  confronted  with  mainlobe  interference,  and  in  the 
absence  of  a  mainlobe  canceller,  the  AI  rulebase  puts  the  radar  in  a  burnthrough 
mode  of  operation.  If  the  jammer  is  declared  to  be  in  the  sidelobes,  a  multiple 
sidelobe  canceller  (MSLC)  or  SLB  may  be  enabled  for  high  or  low  jammer  duty 
factors,  respectively. 

Three  approaches  were  considered  for  supporting  the  mainlobe  versus  the  sidelobe 
assessment: 

1.  Compare  the  jammer  powers  measured  over  all  beam  positions.  Mainlobe  jam¬ 
ming  is  declared  for  those  beams  that  have  substantially  higher  (at  least  the 
mainbeam  to  peak  sidelobe  ratio)  jammer  power  than  the  other  beam  positions. 

2.  Compare,  in  the  ST- 100,  the  jammer  power  in  the  sum  beam  channel  with 
that  in  an  auxiliary  antenna  channel  with  gain  slightly  above  the  sum  beam’s 
sidelobe  level.  Sidelobe  j£imming  is  declared  in  those  time  samples  in  which  the 
auxiliary  channel  power  is  greater  than  the  sum  beam  (similar  in  concept  to  a 
conventional  sidelobe  blanker). 

3.  Implement  a  dedicated  hardware  circuit  that  performs  the  comparison  described 
in  option  (2),  counts  the  number  of  sidelobe  jannmer  declarations  per  PRI,  and 
outputs  this  count  to  the  ST-100  for  determination  of  the  sidelobe  jammer  duty 
factor. 

Option  (1)  is  the  least  expensive  of  the  three  options;  however,  it  is  vulnerable  to  false 
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declarations  in  the  case  of  more  than  one  ASP  jammer  with  diverse  power  levels.  The 
other  two  approaches  perform  better  in  this  situation  because  assessments  can  be 
made  instantaneously  on  each,  time  sample. 

Option  (2)  has  the  disadvantage  of  requiring  two  radar  channels  to  be  interfaced  and 
processed  as  opposed  to  one  lor  the  other  approaches.  Due  to  the  1  MHz  maximum 
data  transfer  rate  into  the  ST- 100,  a  two-channel  interface  would  require  either  halv¬ 
ing  the  radar  bandwidth  to  .5  MHz  and  time-multiplexing  the  ST- 100  input  port, 
or  using  the  FIFO  of  C-Bancl  buffer/mux  to  limit  range  processing  to  half  the  PRI 
extent.  Also,  new  ST-100  software  would  be  needed  to  demultiplex  the  input  data. 

Option  (3)  was  preferred  because  of  synergism  with  the  DSP.  Given  that  sidelobe 
blanker  hardware  was  already  required  for  detection  processing,  o.nly  minor  additional 
circuitry  (counter  and  interface  to  the  header  generator)  was  necessary  to  effect  a 
capability  of  both  sidelobe  blanking  and  sidelobe  jammer  duty  factor  estimation. 
Figure  3-4  illustrates  the  new  circuitry  that  was  implemented  for  these  combined 
functions. 

Isolation  of  Measurements:  la  cases  where  multiple  interference  sources  overlap  in 
the  measurement  time  interval,  identification  of  the  individual  component  interference 
sources  proved  to  be  extremely  difficult,  if  not  impossible  in  some  cases.  For  example, 
a  strong  continuous  wideband  mainlobe  jammer  will  mask  the  entire  range-doppler 
surface  computed  during  CPI2,  precluding  correct  clutter  declarations. 

Eliminating  targets  and  clutter  from  the  jammer  measurements  is  much  easier  than 
eliminating  jamming  from  the  clutter  measurements.  Clutter  and  targets  are  elimi¬ 
nated  from  the  jammer  measurement  by  keeping  the  transmitter  off  during  the  CPU 
measurement  interval.  Unfortunately,  jammer  signals  are  also  prpsent  during  CPI2 
and  tend  to  corrupt  the  clutter  measurements. 

Sidelobe  jammer  levels  during  CPI2  can  be  reduced — ii  not  eliminated — by  using  a 
sidelobe  canceller  for  continuous  januners,  or  sidelobe  blanking  for  pulsed  jamming. 
In  the  case  of  mainlobe  jamming,  a  mainlobe  canceller  would  reduce  the  jamming 
interference  and  mainbeam  gain  on  the  target  would  be  maintained,  provided  that 
there  is  no  more  than  one  jammer  in  the  null-to-null  mainbeam  width.  For  the  demo, 
neither  SLCs  nor  MLCs  were  available;  we  were,  therefore,  faced  with  the  problem  of 
NB  or  WB  CW  jamming  overlapped  with  ground  and  weather  clutter  returns.  Some 
headway  was  made  on  a  rulebase  for  resolving  the  individual  interference  sources  for 
this  situation,  but  it  was  not  implemented.  We  suggest  additional  analysis  of  this 
problem. 
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Figure  3-4:  Sidelobe  Blanker/Sidelobe  Jarrunei  Detection  Circuit 


0  If  B  >  A  (sidelobe  jammer  present) 
1  if  B  <  A  (no  slaelobe  Jammer) 


32 


3.2.3  Detection  Signal  Processing 

The  function  of  DSP  is  to  extract  and  display  targets  from  the  radar  return  during 
CPI3  (see  Section  3.2.2  and  the  functional  requirements  in  Table  4).  We  evaluated 
alternate  RLSF  architectures  with  respect  to  their  capabihties  for  satisfying  goals  1-3 
(listed  at  the  beginning  of  Section  3). 

The  DSP  is  implemented  with  real-time  dedicated  RLSF  hardware.  Figure  2  3  illus¬ 
trates  the  DSP  equipment.  Some  of  the  major  issues  and  tradeoffs  in  the  DSP  design 
were 

1.  Should  the  real-time  signal  processing  functions  (i.e.,  pulse  compression,  MTI, 
CFAR,  and  envelope  detection)  be  performed  using  the  ST-100,  or  could  they  be 
performed  via  a  less-risky  approach  using  the  existing  RLSF  signal  processing 
hardware? 

2.  Although  the  transmit  polarization  can  be  controlled  by  the  DCU  to  be  verti¬ 
cal,  horizontal,  left-circular,  or  right-circular,  the  receive  polarization  antenna 
outputs  are  only  ±45°,  and  thus  don’t  match  any  of  the  transmit  polariza¬ 
tions.  Therefore,  these  receive  polarizations  must  be  formed  by  the  appropriate 
weighted  addition  of  the  existing  -f-45  and  -45°  output  channels.  Should  ded¬ 
icated  analog  hardware,  the  ST- 100,  or  the  Mini-DBF  equipment  be  used  to 
apply  the  appropriate  phase  weights  and  to  add  these  channels. 

3.  What  is  the  best  way  to  perform  the  adaptive  antenna  sidelobe  cancellation? 

4.  Which  interface  (digital  muxed  data  versus  80  MHz  IF  cabling)  should  be  used 
to  transfer  received  data  from  the  antenna  to  the  processing  equipment? 

Each  of  these  issues  will  be  discussed  in  greater  detail. 

3. 2. 3.1  ST-100  Versus  Dedicated  Hardware  Tradeoffs 

Table  4  suggests  that  the  ESP  and  DSP  functional  requirements  are  sufficiently  dif¬ 
ferent  to  have  a  significant  impact  on  loading  if  DSP  were  also  to  be  implemented  on 
the  ST-100.  We  estimated  that  the  ST- 100  is  at  lecist  50  percent  loaded  and  possibly 
more,  depending  on  the  efficiency  of  the  applications  code.  Therefore,  we  believed 
that  performing  DSP  on  the  ST-100  would  substantially  exceed  the  ST-lOO’s  capabil¬ 
ities  for  meeting  the  real-time  requirement.  Dedicated  hardware  was,  therefore,  used 
for  the  DSP. 

Pulse  Compressor  and  Data  Interface:  This  tradeoff  involved  using  one  of  two 
candidate  architectures;  1)  one  or  more  existing  SAW  pulse  compressors,  or  2)  the 
ST- 100  with  an  existing  applications  program.  The  latter  approach  had  the  advantage 


System  Design  and  Development 


33 


of  increased  flexibility  (it  could  accommodate  more  variations  of  waveform  coding), 
but  had  the  disadvantage  of  increased  processing  time. 

Based  on  all  considerations,  we  deemed  the  SAW  compressor  preferable.  It  is  not  as 
flexible  for  compressing  arbitrary  waveforms  as  the  ST- 100,  but  performs  reasonably 
well  with  any  LFM  waveform  that  has  a  frequency  slope  of  .0625  MHz//isec.  For  the 
IMRD  demo,  the  pulse  duration  and  PRF  were  fixed  for  risk  management,  making 
operation  at  lower  than  maximum  bandwidth  unimportant.  Therefore,  the  waveform 
was  fixed  at  1  MKr,  bandwidth  and  16  psec  duration  to  give  the  requisite  frequency 
slope. 

The  following  three  additional  sub-options  were  considered  for  the  SAW  pulse  com¬ 
pressor  implementation: 

1.  Use  two  PCs  (pulse  compressors):  one  for  the  sum-f45,  and  the  other  for  the 
switched  output  of  either  the  sum-45  or  subarray  auxiliary  channel.  The  PCs 
would  be  installed  ahead  of  the  existing  synchronous  detectors  in  the  C-Band 
receive  string,  the  synchronous  detector  digital  outputs  would  be  cabled  to 
the  SPARC  SLC,  and  the  SLC  digital  output  would  be  cabled  to  the  RLSF 
equipment  room  over  a  300  ft.  digital  interface. 

2.  Use  one  PC  in  series  with  the  ROM  Waveform  Generator  (WFG)  connected 
to  the  output  of  the  SPARC  DBF'.  The  PC  output  would  then  be  transferred 
(at  IF)  over  the  300  ft.  coaxial  cable  to  the  RLSF,  connected  to  the  existing  80 
MHz  synchronous  detector,  and  digitized  by  A/D  converters.  The  digital  data 
would  then  be  fed  into  the  A/D  converter  data  input  of  the  mux  board. 

3.  Use  one  PC  at  the  receiving  end  of  a  300  ft.  coaxial  cable  (within  the  RLSF) 
that  carries  an  80  MHz  IF  signal  from  the  C-Band  room. 

Of  the  three  options,  the  first  two  could  be  used  in  conjunction  with  the  SPARC 
SLC;  the  third  was  applicable  only  if  the  SPARC  equipment  was  not  used.  Between 
(1)  and  (2),  the  former  was  preferred;  the  latter  would  only  be  used  in  the  event 
that  the  requisite  300  ft.  digital  interface  was  not  implemented  in  time  for  the  IMRD 
demo.  Option  (2)  had  the  disawivantage  of  introducing  two  additional  error  sources — 
namely,  the  ROM  Waveform  Generator  and  a  second  synchronous  detector — into  the 
data  string. 

Initially  in  the  contract,  we  estimated  that  the  SPARC  SLC  would  be  operational 
in  time  for  the  IMRD  demo,  and  equipment  design  for  option  (1)  proceeded  under 
that  assumption.  However,  we  later  determined  that  technical  problems  with  the 
SPARC  SLC  would  preclude  its  use.  At  that  point,  option  (3)  became  viable  since 
the  architecture  no  longer  required  that  digital  data  be  available  within  the  C-Band 
room  for  input  to  the  SLC.  As  a  result,  the  final  AI  testbed  incorporated  option  (3). 
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For  all  options,  the  pulse  compressor  is  installed  ahead  of  a  synchronous  detector 
which  has  about  C3  dB  of  dynamic  range  (12  bits  I  and  Q).  Considering  the  dynamic 
range  increase  through  the  PC  of  12  dB  (101og(band width  *  time)),  this  restricted 
the  dynamic  range  input  to  the  PC  to  about  51dB.  Throughout  the  equipment  tests 
and  final  demo,  adjustments  were  made  via  variable  attenuators  to  prevent  signals 
from  exceeding  this  dynamic  range  window. 

Doppler  Processing:  Tradeoffs  between  adaptive  MTI  and  the  “doppler  filter 
bcink+greatest  of”  implementation  favored  the  former  option  because  the  effective 
spectr^ll  notch  is  equivalent  with  much  less  complexity.  The  loss  of  integration  gain 
with  MTI  relative  to  a  full  doppler  filter  bank  had  minimal  impact  on  demonstration 
credibility  since  the  C-Band  system  has  the  sensitivity  to  detect  targets  beyond  100 
nmi,  provided  that  pulse  compression  is  used. 

The  adaptive  MTI  was  implemented  using  the  PTF  lab  equipment,  with  the  weight 
sets  calculated  by  the  VAX  computer  using  an  existing  algorithm  developed  by  Sensis. 
The  PTF  accepts  input  data  at  up  to  a  2  MHz  rate;  the  number  of  pulses  is  up  to  16. 

The  weights  are  precomputed  for  different  spectral  regions  and  stored  in  a  table.  A 
weight  set  is  selected,  based  on  environmental  assessment  outputs  that  specify  the 
center  frequency  and  bandwidth  of  ground  and  weather  clutter.  The  wider  the  clutter 
bandwidth  relative  to  the  radar  PRF,  the  more  degrees  of  freedom  (i.e.,  procecsed 
pulses)  are  used  to  implement  a  spectral  notch  encompassing  the  clutter.  Narrow 
spectral  widths,  such  as  those  for  discrete  stationary  scatterers,  require  only  a  two- 
pulse  MTI  to  cancel  to  desired  levels. 

A  requirement,  stated  in  the  manufacturer’s  users  manual,  for  2048  range  samples 
per  PRI  was  misinterpreted  to  mean  “up  to  2048  range  cells”  instead  of  the  manufac¬ 
turer’s  intention  that  “greater  than  2048  range  cells”  be  processed  per  PRI.  During 
equipment  integration  and  test,  we  discovered  that  the  baseline  design — which  had  a 
PRI  of  1  //sec  and  a  sample  rate  of  1  MHz — had  an  insufficient  number  of  samples 
per  PRI  for  the  PTF  to  operate.  An  increase  in  the  PRI  (i.e.,  decrease  in  the  PRF) 
was  therefore  necessary,  making  the  system  less  than  optimal  for  weather  spectral 
measurements  as  well  as  for  weather  cancellation. 

Envelope  Detector:  This  function  is  implemented  using  the  existing  RLSF  equip¬ 
ment  in  cabinet  E-2.  The  sample  rate  through  the  envelope  detector  is  limited  to  2 
MHz  and  the  dynamic  range  is  10  bits,  both  more  than  sufficient  for  demonstrating 
feasibility. 

CFAR/Log  Normalizer:  The  CFAR/Log  Normalizer  implements  the  function  illus¬ 
trated  in  Figure  3-5.  The  RLSF  normalizer  uses  the  geometric  mean  of  the  background 
to  normalize  the  test  cell.  The  number  of  cells  comprising  the  background  estimate 


System  Design  and  DeveJopment 


35 


detector 

Figure  3-5:  CFAR  Equipment  Algorithm 

can  be  either  32,  64,  or  128;  of  these  options,  the  128  was  used  since  the  other  two 
exhibited  excessive  digital  glitch  outputs. 

CFAR  was  not  used  for  the  final  demo  to  enable  a  better  PPI  display  indication  of 
false  alarms  with  and  without  AI  enabled. 

Threshold  Detector  and  Noncoherent  Integration:  Threshold  detection  and  non¬ 
coherent  integration  are  built  into  the  UPA-62  PPI  display,  so  no  additional  circuitry 
was  necessary  for  implementing  these  functions.  Signals  below  approximately  .5  V  in¬ 
put  are  not  displayed,  depending  on  the  sensitivity  adjustment.  Persistence  of  the  PPI 
phosphors  improves  target  detectability  with  increased  dwell  time  (therefore,  more 
target  hits)  ^lnd  approximates  a  noncoherent  integration  function.  The  advantages 
of  reduced  complexity  using  this  technique  far  outweigh  the  slight  loss  as  compared 
with  an  ideal  noncoherent  integrator. 

3. 2. 3. 2  Receive  Polarization 

The  options  for  implementing  a  receive  polarization  that  is  either  matched  or  orthog¬ 
onal  to  the  transmitter  involved  the  following  weighted  combinations  oi  the  -|-45  and 
-45°  sum  channel  outputs: 

1.  Add  the  -|-45  and  -45°  channels  to  yield  horizontal  polarization. 

2.  Subtract  the  -45°  polarization  channel  from  :  <  j  -f45°  channel  to  give  vertical 
polarization. 
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3.  Apply  90®  phase  shift  to  -1-45  channel  and  add  to  -45  channel  to  give  left  circular 
polarization. 

4.  Apply  90®  phase  shift  to  -45  channel  and  add  to  -t-45  channel  to  give  right 
circular  receive  polarization. 

These  calculations  could  be  performed  in  one  of  three  ways:  1)  in  analog  hardware 
at  the  80  MHz  IF  (via  a  power  splitter,  phase  shifter,  power  combiner,  and  switch), 
2)  in  ST-100  software,  or  3)  in  the  SPARC-SLC  digital  equipment. 

The  SPARC-SLC  option  would  have  involved  a  minor  equipment  modification  to 
enable  applying  weights  to  and  summing  two  receive  channels  (-f45  and  -45°)  instead 
of  the  eight  channels  for  which  it  is  designed.  This  was  the  preferred  approach  for 
synthesizing  the  appropriate  polarizations,  but  the  equipment  was  not  operational  at 
the  time  of  the  demonstration. 

The  ST- 100  option  would  have  required  interfacing  the  two  polarization  channels  to 
the  ST-100  input  as  well  as  writing  additional  applications  code.  For  these  reasons, 
as  well  as  to  offload  the  ST-100  for  maximizing  real-time  operation,  this  approach 
was  eliminated. 

Even  though  the  analog  network  requires  precise  line  length,  amplitude,  and  phase 
matching,  it  was  chosen  for  the  final  equipment  configuration.  We  experienced  some 
difficulty  in  adjusting  the  phase  and  time  delay  matching  of  the  input  channels,  but 
eventually  realized  over  35  dB  cancellation  of  an  orthogonally-polarized  wideband 
test  signal  as  well  as  approximately  20  dB  cancellation  of  real  weather  returns  with 
an  orthogonal  transmit  polarization. 

3. 2. 3. 3  Sidelobe  Cancellation 

We  considered  two  options  for  sidelobe  cancellation:  1)  use  the  SPARC-SLC  Mini- 
DBF,  or  2)  implement  this  function  in  the  ST- 100.  We  chose  the  former  option  to 
reduce  ST- 100  functional  throughput  requirements  and  to  enhance  the  capability  for 
real-time  operation.  Other  reasons  which  favored  the  SPARC-SLC  were  that  the 
ST- 100  would  have  required  a  new  software  input  interface  for  demuxing  two  input 
channels  and  that  substantial  additional  applications  code  would  have  been  necessary 
to  implement  the  SLC. 

The  SPARC  processor  in  the  Mini-DBF  would  have  been  used  in  an  operating  mode 
which  implements  a  single  degree  of  freedom  sidelobe  canceller.  This  would  have 
required  that  the  SPARC-SLC  Mini-DBF  equipment  receive  digital  inputs  for  the 
sum  and  a  single  auxiliary  beam.  The  auxiliary  would  have  been  one  of  the  subarray 
channels  of  the  array. 
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3. 2.3.4  Data  Interface 

Paragraph  2  in  Section  3.2.3. 1  discusses  the  three  candidate  data  interface  approaches, 
Elach  is  related  to  different  implementations  of  the  pulse  compressor  and  depends  on 
operational  SPARC-SLC  equipment. 

The  initial  design  involved  using  the  SPARC-DBF  with  a  digital  output  interface  to 
the  RLSF,  300  ft.  away.  The  output  interface  was  to  consist  of  a  Hot  Rod  interface 
card  at  each  end  of  the  cable.  The  card  at  the  SPARC-DBF  output  end  of  the  cable 
would  have  taken  parallel  word  inputs,  converted  them  to  a  serial  bit  stream,  then 
sent  the  serial  data  over  a  300  ft.  coaxial  cable  interface  to  the  PLSF.  On  the  receiving 
end  of  the  cable,  another  Hot  Rod  card  would  convert  the  serial  data  stream  back  to 
parallel  for  input  to  the  PTF  and  ST-100. 

The  need  for  a  300  ft.  digital  interface  was  driven  by  the  SPARC-DBF,  which  h^ls 
a  digitsJ  input/output  and  is  installed  in  the  C-Band  room.  An  alternate  interface 
(see  Section  3.2.3. 1,  paragraph  2)  was  a  fallback  in  the  event  that  the  Hot  Rod  was 
unavailable.  This  option  would  have  used  the  ROM  Waveform  Generator  at  the 
SPARC-DBF  output  instead  of  the  Hot  Rod  transmitter  to  modulate  the  signal  on 
an  80  MHz  IF  for  transfer  to  the  RLSF  where  the  signal  would  have  been  converted 
back  to  digital  via  the  existing  80  MHz  synchronous  detector. 

Since  the  SPARC-DBF  was  unavailable,  neither  of  the  interface  options  discussed 
above  were  used.  Instead,  the  IF  signal  from  the  array  was  transferred  directly  to  the 
RLSF  over  a  300  ft.  coaxial  cable  to  the  RLSF  synchronous  detector,  thus  bypassing 
the  synchronous  detectors  in  the  C-Band  room.  Figure  2-3  illustrates  this  interface. 
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3.3  Adaptive  Control 

The  IMRD  objective  is  to  identify  targets  in  the  presence  of  clutter  and  jaminer 
interference.  Adaptive  control  requirements  in  support  of  this  objective  are: 

1.  Receive  raw  radar  data  on  a  beam-by-beam  basis. 

2.  Identify  factors  that  impact  system  performance. 

3.  Determine  what,  if  any,  changes  can  be  made  in  operating  conditions  so  as  to 
improve  performance. 

4.  Select  an  operating  plan  for  the  next  scan  that  optimizes  system  performance. 

5.  Send  control  parameters  for  the  next  scan  to  the  radar. 

Section  3.3.1  discusses  the  initial  tradeoffs  made  in  the  Adaptive  Controller  design. 
Sections  3.3.2  through  3.3.4  detail  the  resulting  implementation. 

3.3.1  Tradeoffs 

The  Adaptive  Controller  design  required  a  series  of  studies  to  determine  the  following: 

1.  A  means  of  assessing  the  effectiveness  of  an  adaptive  control  policy  (Sec¬ 
tion  3.3. 1.1). 

2.  Categories  of  interference  that  impact  target  detection  (Section  3. 3. 1.2).  Partic¬ 
ular  emphasis  was  placed  on  those  that  could  be  identified  in  and  compensated 
for  in  the  RLSF  environment,  and  on  techniques  that  could  be  applied  to  miti¬ 
gate  the  identified  interference. 

3.  Policy  control  decisions  that  should  be  made  by  the  user;  for  example,  the 
ability  to  prioritize  regions  of  coverage  and  to  constrain  system  resources  such 
as  scan  time  (Section  3. 3. 1.3). 

4.  Which  programming  languages  to  use  (Section  3. 3. 1.4). 

3. 3. 1.1  Evaluation  Criteria 

Evaluating  the  impact  of  an  adaptive  control  policy  on  subsequent  radar  performance 
is  necessary  for  two  reasons.  First,  the  AI  component  of  the  Adaptive  Controller  must 
be  able  to  select  among  alternate  operating  plans  before  one  is  implemented.  Second, 
a  measure  of  adapti  ve  control  effectiveness  after  a  plan  is  implemented  is  needed  to 
demonstrate  the  accomplishments  of  this  contract. 
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A  priori  evaluation  is  required  by  the  AI  software  when  generating  a  plan  for  the 
next  scan.  Alternate  operating  plans  will  assign  different  amounts  of  dwell  time  to 
the  individual  beams,  with  better  target  detection  associated  with  higher  levels  of 
dwell  time  per  beam.  For  purposes  of  pohey  selection  within  the  adaptive  control 
softwcire,  we  used  a  computed  probability  of  detection  estimate  as  a  criterion  for 
selecting  between  two  choices  and  as  a  measure  of  control  effectiveness. 

The  probability  of  detection  calculation  assumes  a  conventional  Bayesian  likelihood 
ratio  test  comparing  the  received  signal  with  a  threshold  normalized  to  the  inter¬ 
ference  background.  The  target  is  assumed  to  be  slowly  fluctuating  with  Rayleigh 
statistics  (i.e.  Swerling  I)  and  the  false  alarm  probability  is  maintained  at  10"®  per 
range  cell  via  a  CFAR  threshold.  Other  false  alarm  rates  or  target  models  could  be 
accommodated  with  minor  changes  to  the  software. 

In  addition  to  probability  of  false  alarm  and  target  statistics,  the  detection  probability 
is  a  function  of  the  net  signal-to-interference  ratio  (SIR),  the  interference  statistics, 
and  the  number  of  looks  that  are  noncoherently  integrated  by  the  signal  processor.  To 
simplify  the  AI  testbed,  the  spatial  distribution  of  clutter  is  assumed  to  be  Rayleigh, 
and  the  other  variables  are  accounted  for  via  a  table  lookup. 

The  SIR  estimate  is  based  on  actual  measurements  of  the  interference- to-noise  ratio 
and  the  calculated  SNR  for  a  user-specified  cross  section  and  detection  range.  The 
SNR  calculation  includes  other  parameters  of  the  radar  range  equation-such  as  aver¬ 
age  power,  antenna  gain,  and  losses-which  are  stored  in  the  Radar  Design  Parameters 
file  for  the  specific  radar. 

A  posteriori  evaluation  of  adaptive  control  effectiveness  is  more  difficult.  Given  knowl¬ 
edge  of  the  true  radar  environment,  one  could  compare  the  number  of  detected  targets 
and  false  alarms  with  AI  enabled,  and  evaluate  the  same  scene  without  AI  enabled. 
On  a  single  scan  basis,  it  is  unlikely  one  will  know  what  the  real  environment  is  and 
whether  an  identified  target  is  real  or  is  a  false  alarm;  hence,  this  approach  is  not 
practical  in  a  real-time  demonstration  of  target  detection.  However,  it  was  effectively 
used  to  verify  identification  and  countering  interference  such  as  jammers  that  could 
be  controlled  from  the  RLSF. 


3. 3. 1.2  Interference 

Section  3.1.2  summarizes  the  L-Band/C-Band  tradeoffs  and  establishes  what  adap¬ 
tive  controls  can  be  achieved  with  the  C-Band  radar.  Given  the  choice  of  C-Band 
radar,  we  next  considered  what  types  of  interference  caji  be  identified  that  impact 
system  performance,  v^hich  adaptive  controls  can  be  applied  to  them,  and  what  can 
be  demonstrated  within  the  RLSF  environment. 
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Types  of  Interference;  Two  types  of  interference  appear  in  the  radar  signal:  that 
which  can  be  detected  by  listening  (which  shall  be  denoted  passive  interference)  and 
that  which  can  be  detected  in  the  returns  of  a  transmitted  waveform  (which  shall 
be  denoted  active  interference).  The  first  category  includes  various  types  of  nonre- 
sponsive  jammers  and  radio  frequency  interference  (RFI);  the  second,  grou.nd  and 
weather  clutter,  chaff,  and  responsive  jammers.  This  distinction  led  to  including  a 
pcissive  hstening  interval  and  an  active  assessment  interval  in  each  beam  dwell  prior 
to  the  detection  waveform.  See  Section  3.2.2  for  a  full  description  of  the  beam  dwell 
partition. 

Nonresponsive  jammers  are  sensed  during  the  passive  dwell.  They  will  show  up  as 
threshold  crossings  in  the  power  level  for  consecutive  PRls.  They  can  be  discriminated 
by  narrowband  versus  wideband,  CW  versus  asynchronous  pulsed,  and  mainlobe  ver¬ 
sus  sidelobe. 

Measures  of  ground  and  weather  clutter  are  made  during  the  active  dwell  via  a 
Doppler  filter  bank.  Ground  clutter  shows  up  in  radar  data  as  threshold  crossings  near 
zero  doppler  and  range  out  to  the  radar  hoiizon  (except  in  anomolous  propagation 
conditions).  Weather  clutter  shov.'s  up  as  threshold  crossings  at  ranges  corresponding 
to  its  location  and  at  doppler  corresponding  to  weather  radial  velocity.  If  the  weather 
is  near  the  transmitter  with  a  velocity  vector  tangential  to  the  beam,  it  is  expected 
to  lie  in  the  same  range-doppler  ceils  as  ground  clutter.  If  jammers  are  present,  they 
will  mask  both  ground  and  weather  clutter;  hence,  ground  and  weather  clutter  will 
not  be  visible  unless  appropriate  adaptive  controls  have  been  applied  during  CPI2  to 
detected  jammers. 

We  have  maintained  a  growth  path  to  other  categories  of  interferenc.e  such  as  chaff 
and  responsive  jamming. 

Adaptive  Controls:  The  following  adaptive  controls  can  be  applied  within  the  RLSF 
environment: 

1.  Narrowband  jammers:  frequency  change,  growth  to  sidelobe  canceller. 

2.  Pulsed  sidelobe  jammers:  sidelobe  blanking. 

3.  CW  sidelobe  jammers:  sidelobe  cancelling. 

4.  Ground  clutter:  adjustable  MTI  weights. 

5.  Weather  clutter:  receive  and  transmit  polarization,  adjustable  MTI  weights. 

6.  All:  dwell  time  per  beam. 


Development  and  Demonstration:  Existing  RLSF  equipment  includes  two  fixed  C- 
Band  jammer  sources,  which  can  simulate  pulsed  and  CW  narrowband  and  wideband 
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jammers.  The  jammers  can  be  used  to  investigate  system  time  and  performance 
response  to  jammer  interference.  They  are  remotely  controlled  from  the  HP2117 
terminal  in  the  RLSF  equipment. 

dround  and  weather  clutter  provide  interference  to  be  sensed  in  the  active  dwell. 
Within  the  RLSF  environment,  ground  clutter  extends  out  to  about  twenty  miles 
from  the  transmitter.  Its  intensity  can  be  increased  by  aiming  the  antenna  down 
or  decreased  by  aiming  it  up.  Weather  clutter  control  is  limited  for  testing  and 
demonstration. 

Targets  of  opportunity  and  simulated  targets  were  illuminated  in  the  clear  for  system 
verification  and  in  competition  with  the  various  clutter  and  jamming  sources  for 
demonstration.  Targets  on  final  approach  to  GAFB,  Syracuse  Hancock,  and  Oneida 
County  Airports  were  of  interest  since  they  appear  in  the  ground  clutter. 

We  concluded  that  these  categories  of  interference  were  sufficiently  representative  and 
testable  to  exercise  our  rulebase  development  methodology  and  to  permit  a  meaning¬ 
ful  demonstration.  Our  procedure  for  developing  and  testing  the  rulebase  was: 

1.  Develop  and  test  rules  for  identifying  individual  sources  of  interference  and 
applying  appropriate  ECCM. 

2.  Repeat  step  (1)  with  multiple  sources  of  interference. 

3.  Develop  rules  for  allocating  dwell  time  and  evaluate  them  with  simulated  tar¬ 
gets. 

Recorded  radar  returns  allowed  rulebase  development  for  interference  identification 
without  repeatedly  needing  to  turn  on  the  radar  and  transmitter.  This  played  an 
important  role  in  step  (1)  which  required  successive  iterations  to  fine-tune  the  rules. 
With  respect  to  live  testing,  weather  needed  to  be  tested  as  opportunities  arose,  but 
the  other  sources  of  interference  could  be  tested  with  live  data  at  any  time. 

Thus,  we  obtained  representative  classes  of  interference  for  which  adaptive  controls 
existed  within  the  RLSF  and  whicli  were  available  for  development  and  demonstra¬ 
tion. 


.S.3.1.3  User  Policy  Control 

The  IMRD  allows  user  inputs  consistent  with  iactir.al  objectives.  For  exam.ple,  a  piece 
of  equipment  such  as  a  sidelobe  blanker  may  bo  unavailable,  track- while-scan  data 
rate  requirements  may  dictate  a  scan  time  requirement,  or  the  operator  may  wish  to 
factor  in  the  relative  importance  of  regions  of  coverage.  These  capabilities  are  built-in 
through  user-selectable  AI  Control  Parameters,  Quality  Options,  and  Priority  Zones. 
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High 


Figure  3-6:  Priority  Zone  Example 


Additionally,  the  user  can  control  the  A1  Display  through  AI  Output  Parameters. 
The  rulebase  will  then  tailor  its  decisions  to  accommodate  these  inputs. 

AI  Control  Parameters:  The  user  can  assign  va’ues  (such  desired  scan  time, 
whether  AI  is  enabled,  and  which  adaptive  controls  can  be  applied)  to  AI  Control 
Parameters.  They  are  either  read  from  a  file  or  entered  interactively  on-line  at  system 
initialization,  and  may  be  modified  during  operatn  n  either  on-line  or  by  reading  a 
new  file.  This  data  structure  is  described  in  Appei  <  E.2. 

Priority  Zones:  Regions  under  radar  surveillance  an  be  partitioned  into  Priority 
Zones  based  on  their  expected  threat  level  and  the  importance  of  maintaining  de¬ 
tection  within  tb'^m.  Five  types  of  threat  regions  (high,  medium,  low,  friendly,  and 
unoccupied)  arc  ified  by  near  and  far  range  and  by  start  and  stop  azimuth. 

Figure  3-6  illustrates  a  Priority  Zone  configuration  that  Wcis  used  to  demonstrate 
differential  dwell  time  allocations  under  various  types  of  interference.  In  this  example, 
the  first  beams  of  the  scan  region  are  of  highest  priority,  w'ith  regions  of  decreasing 
importance  in  a  clockwise  rotation. 

A  beam  may  contain  more  than  one  priority  level  with,  for  example,  a  higher  priority 
region  near  the  transmitter  and  a  lower  one  further  out.  At  present,  for  purposes  of 
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adaptive  control,  the  entire  beam  is  considered  to  be  at  the  highest  level  it  contains. 

Priority  Zones  may  be  entered  from  a  file  or  edited  on-line.  A  default  level  of  un¬ 
occupied  is  associated  with  unassigned  zones.  This  data  structure  is  described  in 
Appendix  C.2. 

Quality  Options:  Beam  dwell  time  is  adaptively  apportioned  to  different  beams  by 
the  Adaptive  Controller  based  on  a  set  of  alternate  plans  stored  in  a  Quality  Options 
Table.  A  quality  plan  assigns  a  probability  of  detection  to  each  priority  level.  The 
Quality  Options  Table  contains  up  to  eight  plans,  ordered  by  decreasing  probabilities 
of  detection  in  each  of  the  priority  zones.  The  Adaptive  Controller  selects  the  first 
plan  that  can  execute  within  the  desired  scan  time. 

A  typical  set  is  given  in  Table  6.  In  plan  (1),  all  regions  are  assigned  the  highest  Pd. 
If  the  scan  time  required  to  meet  the  Pd  of  .9  in  each  region  exceeds  the  user-specified 
upper  limit,  a  plan  will  be  selected  in  which  less  time  is  used  for  lower- level  threat 
regions  relative  to  the  higher  threat  regions.  In  plan  f8),  for  example,  dwell  time  is 
assigned  to  the  high  and  medium  threat  regions  and  others  are  skipped. 

If  there  is  insufficient  time  to  satisfy  any  of  the  first  eight  plans,  the  Adaptive  Con¬ 
troller  chooses  a  default  plan  (9).  This  default  may  be  required  when  there  is  strong 
interference  background  and/or  when  the  system  is  stressed  by  a  low  desired  radar 
cross  section  (RCS)  or  a  large  desired  detection  range.  In  this  case,  dwell  time  is 
assigned  to  the  high  threat  zones  so  as  to  obtain  the  highest  probability  of  detection 
possible  within  the  total  scan  time  constraint. 

Note  that  even  if  two  beams  are  at  the  same  threat  level,  they  may  not  be  assigned  the 
same  dwell  time  under  a  plan.  This  can  happen  in  the  case  that  there  is  interference 
in  one  beam,  requiring  more  time  to  reach  the  same  Pd  as  another  beam  in  which 
there  is  no  interference. 

Quality  Options  also  include  passive  and  active  update  rates  (not  shown  in  Table  6) 
to  indie.,  ce  how  frequently  the  passive  and  active  dwells  for  each  beam  should  be 
repeated.  During  IMRD  development  and  testing,  we  assumeri  that  update  occurs  on 
each  scan  to  meet  the  SOW  requirement  for  a  one  scan  response  time,  but  it  might 
make  sense  to  update  beams  at  lower  priority  levels  or  regions  in  which  no  interference 
is  identified  less  frequently. 

Also,  it  should  be  noted  that  a  variable  other  than  Pd  might  be  appropriate  for  the 
table  entries  in  some  other  applications.  For  example,  the  entries  could  be  detection 
range  for  a  fixed  Pd  (say  .9)  and  a  fixed  target  RCS,  or  could  be  RCS  for  fixed  Pd 
and  detection  range. 

The  Qu2ility  Options  Table  is  read  from  a  file  or  entered  interactively  at  system 
initialization.  It  may  be  modified  during  operation  either  on-hne  or  by  reading  in  a 
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Priority  Level 

Overall  Quality  Option 

t 

X 

2 

3 

4 

5 

6 

7 

8 

9 

High  threat 

.9 

.9 

.9 

.9 

.9 

.7 

.7 

.5 

♦ 

Medium  threat 

.9 

.9 

.9 

.7 

.5 

.5 

.4 

.3 

0 

Low  threat 

.9 

.9 

.7 

.5 

.5 

.3 

0 

0 

0 

Friendly 

.9 

.7 

.5 

.5 

.3 

0 

0 

C 

0 

Unoccupied 

.9 

.6 

.5 

.3 

0 

0 

0 

0 

0 

*  As  high  as  possible  within  p.can  time  constraint. 


Table  6:  Sample  Quality  Options  Table 


new  file.  Full  descriptions  of  Quality  Options  Tables  and  sample  input  are  given  in 
Appendix  D.3. 

AI  Output  Parameters:  These  variables  define  the  types  of  information  and  des¬ 
tinations  of  outputs  the  user  may  display  or  record  during  a  session.  AI  Output 
Parameters  are  read  from  a  file  or  entered  interactively  at  system  initialization  and 
may  be  modified  during  operation  either  on-line  or  by  reading  a  new  file.  This  data 
structure  is  described  in  Appendix  F.2. 


3. 3. 1.4  Choice  of  Languages 

The  IMRD  SOW  stated  that,  unless  it  could  be  justified  that  some  other  choice  wu 
more  appropriate,  Prolog  was  to  be  used  for  '  I  (the  expert  system)  and  either  Pascal 
or  FORTRAN  could  be  used  for  other  com,..>nents.  With  this  in  mind,  we  selected 
the  language  that  was  most  appropriate  for  each  component. 

We  used  Prolog  as  a  starting  point  for  language  decisions  because  it  was  the  basis 
for  the  prior  AI  simulation  and  because  of  its  reputation  as  an  AI  language.  The 
advantages  of  Prolog  are: 

1.  We  could  use  code  developed  under  the  previous  contract. 

2.  Prolog  predicates  are  a  convenient  way  to  express  expert  system  rules. 

3.  Prolog’s  buili-in  inferencing  capabilities  eliminate  the  need  to  code  an  inference 
engine. 

4.  Prolog  is  considerably  more  readable  than  LISP  (the  other  logical  choice  for  AI 
language),  making  it  especially  appropriate  for  a  project  in  which  the  ndebase 


System  Design  and  Development 


45 


was  expected  to  evolve, 

5.  The  foreign  language  interface  capability  in  Quintus  Prolog  (the  available  com¬ 
piler)  supports  integration  of  routines  written  in  other  languages. 

6.  Quintus  Prolog  has  acceptable  run-time  performance. 

The  disadvantages  of  Prolog  are: 

] .  Prolog  has  poor  facilities  for  data  structuring.  Values  for  a  single  variable  and 
for  simple  lists  can  be  asserted  into  the  Prolog  database,  but  the  ability  to 
declare  variables  and  to  organize  information  into  a  record  structure  is  missing. 
Since  one  IMRD  goal  was  to  support  transfer  to  other  hardware  environments 
through  parametiization,  this  was  a  serious  shortcoming. 

2.  Prolog  has  poor  facilities  for  procedural  abstraction.  There  is  no  distinction 
between  load  and  global  \ariables.  This  makes  information  hiding  difficult, 
and  means  that  more  care  must  be  taken  to  modularize  a  program. 

3.  Prolog  cannot  be  used  for  direct  interaction  with  the  VMS  operating  system 
and,  hence,  is  inappropriate  for  mailbox  utilities,  process  spawning,  the  ST- 100 
Host  process,  and  the  VAX/HP2117  interface. 

The  final  solution  was  a  combination  of  Prolog,  Pascal,  and  FORTRAN.  Table  7 
summarizes  the  uses  for  each.  We  found  the  Prolog-Pascal-FORTRAN  combination 
effective,  using  the  capabilities  of  each  language  well. 

3.3.2  Knowledge  Engineering 

Knowledge  engineering  consisted  of  a  precise  definition  of  inputs  derived  from  the 
radar  signals  and  outputs  to  the  Radar  Controller,  subproblem  decomposition  of  the 
Adaptive  Controller  (expert  system),  and  rulebase  evolution. 

3.3.2. 1  Expert  System  I/O 

Defining  expert  system  data  inputs  and  control  parameter  outputs  was  an  iterative 
process  with  the  corresponding  parameters  evolving  as  our  understanding  of  hardware 
and  software  capabilities  broadened.  The  inputs  are  organized  in  a  Pciscal  data  struc¬ 
ture  called  Beam  Scan  Data.  The  outputs  are  organized  in  a  Pascal  data  structure 
called  Radar  Control  Parameters. 

Beam  Scan  Data  Inputs:  We  defined  Beam  Scan  Data  to  correspond  to  signal 
processing  capabilities  and  adaptive  control  objectives.  One  Beaun  Scan  Data  record 
for  each  beam  is  derived  from  ST-100  inputs,  16  PRIs  of  passive  dwell  listening  data. 
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16  PRIs  of  active  dwell  data,  and  a  measurement  of  the  sidelobe  jaiimier  duty  factor. 
It  contains: 

1.  PassiveJDwell-Range-Power:  An  array  whose  components  contain  the  power 
level  returned  from  the  passive  listening  dwel’  lor  consecutive  averaged  range 
blocks  in  each  of  eight  PRIs.  Only  the  first  eight  of  the  16  CPU  PRIs  are 
currently  used.  See  Figure  3-2. 

2.  Pan8ive_DwelLFreq_Poweri  An  array  whose  components  contain  the  FFT  of 
the  complex  voltages  of  all  range  cells  for  each  PRI.  See  Figure  3-2. 

3.  Active-DwellJPower;  An  array  v'hosc  components  represent  the  doppler  filter 
bank  calculated  over  the  16  PRIs  of  the  active  listening  dwell.  See  Figure  3-3. 

4.  Sidelobe_Sum:  An  array  representing  the  number  of  time  samples  in  which 
sidelobe  jamming  was  sensed  in  the  passive  listening  dwell  for  each  PRI. 

The  following  aie  computed  ai/d  allow  for  future  growth,  but  are  not  used  in  the 
present  rulebase.  The  variability  can  be  used  as  a  further  discriminant  among  multiple 
sources  of  interference. 

1.  PessEveJDwelLRange-Var:  An  array  whose  components  contain  the  variabilty 
of  the  power  level  returned  from  the  passive  listening  dwell  for  consecutive  range 
cells  in  each  of  eight  PRIs. 

2.  ActiveJDwelLVar:  An  array  whose  components  contain  the  square  of  the 
doppler  filter  bank  calculated  over  the  16  PRIs  of  the  active  listening  dwell. 

The  scan  information  is  received  from  the  ST-100,  then  forwarded  to  the  Adaptive 
Controller  irom  a  VMS  mailbox.  This  data  structure  is  described  mere  fully  in 
Appendix  G.2. 

Radar  Control  Parameter  Outputs;  We  defined  Radax  Control  Parameters  based  on 
ouf  determination  of  potentially-controUable  parameters  during  the  tradeoff  studies 
and  on  their  expected  impact  on  subsequent  radar  performance.  This  data  is  sent 
by  the  Adaptive  Controller  to  the  VMS  mailbox  from  which  it  i.s  forwarded  by  the 
interface  to  the  HP2117  computer.  It  contains  fields  for  the  following  information: 

1 .  Trans-CeiiterJPreq:  The  frequency  to  use  for  the  beam  position.  The  software 
can  control  up  to  16  unique  frequencies;  hov.^ever,  the  IMRD  system  uses  only 
eight.  This  index  is  translated  by  the  HP2ir7  to  a  real  frequency  value. 

2.  ECCMs_On:  Whether  a  given  ECCM  should  be  on.  The  components  are 
Sidelobe_3lanking  Sidelobe_Cancell;ng,  ard  CFAR. 
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3.  PB.I:  The  pulse  repetition  interval  to  use  for  the  beam  position.  It  can  assume 
values  between  1  and  4096  microseconds.  Within  the  IMRD,  the  value  is  set  to 
3000. 

4.  Pulse-Duration:  The  pulse  duration  for  the  beam  position.  It  can  assume 
values  between  0  and  40  microseconds.  Within  the  IMRD,  the  value  is  set  to 
16. 

5.  Pulse-Bandwidth:  The  pulse  bandwidth  for  the  beam  position.  It  can  assume 
values  between  0  and  10  MHz.  Within  the  IMRD,  the  value  is  set  to  1. 

6.  TX-Polarization:  The  antenna  polarization  to  use  for  transmitting  in  the 
beam  position.  Possible  values  include  Horizontal,  Vertical,  Left-Circular,  and 
Right-Circular.  Within  the  IMRD,  the  value  is  Horizontal  or  Vertical. 

7.  RX-Polarization:  The  antenna  polarization  to  use  for  receiving  in  the  beam 
position.  Possible  values  include  Horizontal,  Vertical,  Left-Circular,  and 
Right-Circular.  Within  the  IMRD,  the  value  is  set  to  Horizontal. 

8.  Afiaptive„MTI_ Weights:  One  of  64  possible  MTI  weights  sets.  In  the  IMRD, 
37  unique  sets  are  used;  the  number  64  represents  the  default  weight  set. 

9.  Dwell-Time_per-Look:  The  PRI  for  CPI3.  The  values  range  from  1  to  1000 
msec. 

10.  Number  jofLLooks:  The  number  of  pulses  to  be  used  in  CPI3.  The  values  range 
from  0  (indicating  tnat  CPI3  should  be  skipped)  to  10000. 

11.  PassiveJDwell-On:  Whether  CPU  should  be  included.  Within  the  IMRD,  the 
value  is  set  to  true, 

12.  Active-Dwell-On:  Whether  CPI2  should  be  included.  Within  the  IMRD,  the 
value  is  set  to  true. 

As  indicated  in  their  descriptions,  not  all  fields  are  controlled  under  this  hardware 
implementation — they  are  included  to  allow  different  radar  control  configurations. 
This  data  structure  is  described  more  fully  in  Appendix  H.2. 

3. 3. 2. 2  AI  Subproblem  Decomposition 

Figure  2-5  shows  a  breakdown  of  the  subproblems  that  contribute  to  assigning  Radar 
Control  Parameters  for  each  scan:  ID  Paissive  Iiiierference,  ID  Active  Interference, 
Determine  Applicable  ECCM,  and  Allocate  Radar  Resources.  The  following  sections 
summarize  these  rulebases.  Their  complete  specification  is  given  in  Appendix  1.6.3. 


48 


3. 3. 2. 2.1  ID  Passive  Interference 

This  subproblern  identifies  jammers  in  a  beam  from  the  passive  dwell,  CPU  (using 
Beam  Scan  Data  variables  PassiveJDwellJlangeJPower,  Passive_DweHJ^req_Power, 
and  SidelobeJSum  described  in  Section  3.3.2. 1).  Figure  3-7  summarizes  the  steps  and 
discriminants  used. 

1.  The  first  step  is  to  determine  whether  any  jammers  are  present  by  examining 
the  Passive_Dwell_Hange_Power  (the  power  level  in  consecutive  range  cells  for 
each  PRI).  If  any  of  its  elements  exceeds  a  threshold,  a  januner  of  some  type  is 
cissumed  to  exist. 

2.  The  rulebase  then  determines  whether  a  CW-type  jammer  is  present  by  cal¬ 
culating  the  peak- to- average  power  ratio  for  the  Passive_Dwell..Range_Power. 
This  is  calculated  for  each  PRI;  the  largest  value  (Range. Var)  is  used  to  deter¬ 
mine  the  janmiei  type.  A  small  Range.Var  indicates  a  CW  jammer.  A  large 
Range. Var  indicates  that  the  jammer  is  pulsed  or  of  some  other  unknown  type. 

3.  If  the  jammer  is  CW,  Freq.Var,the  peak- to- average  poiver  ratio  for  the  Pas- 
sive-Dwell-FreqJ-'ower,  (the  FFT  of  the  chosen  PRI)  is  calculated  using  PRI  1. 
A  low  Freq-Var  indicates  v.’ideband  jammer,  a  high  value  indicates  narrowband 
The  SidelobeJDutyJFactor  is  calculated  by  comparing  the  SidelobeJsum  values 
(the  number  of  time  samples  where  the  auxiliary  voltage  is  greater  than  the 
sum  voltage)  from  each  PRI  and  selecting  the  one  that  occurs  most  frequently. 
If  Sidelobe-DutyJF'actor  exceeds  a  threshold,  a  sidelobe  jammer  is  declared; 
otherwise,  a  mainlobe  jammer  is  declare<rl. 

4.  Determining  whether  a  jammer  is  pulsed  or  of  some  unknown  type  is  more 
involved  than  the  CW  determination.  A  mainlobe  duty  factor  estimate  is  cal¬ 
culated  for  each  PRI  in  order  to  determine  whether  the  jammer  is  pulsed  (duty 
factor  less  than  or  equal  to  ten  percent)  or  of  some  other  unknown  type.  Exper¬ 
imentation  with  thresholding  techniques  indicated  that  an  adaptive  threshold 
gives  the  best  results  due  to  variability  in  the  thermal  noise  level;  we  decided 
to  use  an  adaptive  threshold  that  was  midway  betweim  the  peak  and  average 
value  of  the  passive  range  vector  for  a  particular  PRI.  The  PRI  with  the  largest 
duty  factoi  is  chosen  to  determine  the  bandwidth  of  the  interference.  This  re¬ 
quirement  was  placed  on  the  software  since  the  jammer  returns  may  be  eclipsed 
during  some  of  the  PRIs  due  to  dead  time  in  some  interval.  K  more  than  one 
PRI  qualifies,  the  PRI  with  the  pulse  closest  to  the  center  of  the  range  vector 
is  used.  This  last  qualiheation  was  added  because  we  found  that  the  Freq.Var 
calculation  was  more  accurate  if  the  pulse  was  in  the  center  of  the  processed 
data  due  to  weighting  employed  in  the  time  dimension.  This  was  especially  true 
of  low-power  jammers.  At  this  point,  the  specific  type  of  jammer  is  determined 
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Figure  3-7:  ID  Passive  Interference  Flow 
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from  the  MainlobeJDuty_Factor,  the  Freq.Var,  and  the  Sidelobe_Duty .Factor, 
as  described  above, 

5.  Jammers  are  asserted  into  the  Prolog  database  as  jammerJound  facts  with 
variables  describing  the  specific  type  of  jammer  found,  the  peak  jammer-to- 
noise  ratio,  and  the  duty  factor. 


3. 3. 2. 2. 2  ID  Active  Interference 

This  subproblem  determines  which  types  of  clutter  are  present  from  the  Ac- 
tiveJDwell-Power.  The  input  data  on  which  decisions  are  based  is  the  response  of 
16  doppler  filters  over  a  900  microsecond  range  interval  during  CPI2.  For  the  current 
rulebase  discrimination  of  the  each  of  the  types  of  interference  is  based  on  recognizing 
patterns  that  emerge  on  this  range-doppler  surface.  Examples  of  patterns  are  given 
in  Figure  3-8  which  indicates  range-doppler  regions  in  which  interference  would  likely 
occur  for  the  various  environments. 

The  ID  Active  Interference  rules  then  find  the  best  match  of  the  measures  range- 
doppler  response  with  prestored  maps,  each  representing  the  expected  range-doppler 
surface  for  a  different  clutter  environment.  The  criteria  for  determining  which  map 
most  closely  resembles  the  measurement  is  based  on  the  power  cailculation  over  the 
segmented  zones  and  the  pattern  of  threshold  crossings  as  described  below. 

The  veirious  maps  are  boolean  arrays  with  dimension  equal  to  the  input  array  (16 
doppler  rows  x  30  range  samples).  These  maps  contain  values  of  true  or  false  for 
each  range-doppler  cell,  depending  on  whether  the  particular  type  of  clutter  could 
reasonably  occur. 

Two  types  of  interference  maps  are  incorporated  into  the  current  rulebase:  ground 
clutter  and  weather  clutter.  For  this  demonstration  we  used  ground  clutter  maps  with 
trues  in  the  doppler  filters  that  overlap  the  DC  response  out  to  the  range  horizon, 
but  falses  elsewhere.  The  weather  map  contains  values  of  true  or  false  for  each  range- 
doppler  cell  depending  on  whether  weather  clutter  could  reasonably  occur  within 
it. 

This  technique  is  a  two  dimensional  extension  of  a  concept  developed  under  the 
previous  Rome  Laboratory  AI  work  (ACMDSP,  Contract  F30602-86-C-0204),  and 
represents  a  logical  compromise  between  simphcity  and  performance  for  the  initial 
software  build.  An  early  set  of  rules  calculated  the  size  and  power  of  clusters  of 
threshold  crossings  in  the  active  dwell  Beam  Scan  Data.  Since  these  calculations 
required  a  lot  of  CPU  time  and  were  difficult  to  modify  and  expand,  we  used  the 
predetermined  boolean  maps  to  indicate  for  which  array  elements  within  the  active 
dwell  power  array  we  expect  to  see  threshold  crossings  for  a  given  type  of  interference. 
Now  that  real-time  performance  has  been  established,  we  recommend  further  ruleba.se 
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Figure  3-  8:  Interference  Patterns  in  Range-Doppler  Space 


52 


experimentation  rulebase  to  enable  more  sophisticated  identification. 

Figure  3-9  summarizes  the  steps  and  discrinunants  used. 

1.  Several  discrinunants  are  calculated  over  these  maps  including  the  sum  of  the 
power  over  the  map,  the  percentage  of  matching  threshold  crossings,  and  the 
percentage  of  noc-matching  threshold  crossings.  The  active  dwell  thermal  noise 
array  multiplied  by  a  constant  is  used  to  threshold  the  active  dwell  array. 

2.  The  power  calculation  and  the  percentage  of  matching  threshold  crossings  over 
the  grotmd  clutter  map  are  made.  Ground  clutter  is  declared  if  the  calculations 
over  the  ground  clutter  map  are  above  specified  thresholds, 

3.  The  power  calculation  and  the  percentage  of  matching  threshold  crossings  over 
the  weather  clutter  map  are  made.  Weather  clutter  is  declared  if  the  calculations 
over  the  weather  map  are  above  specified  thresholds. 

4.  If  ground  clutter  is  found,  a  ground„clutter  fact  is  asserted  into  the  Prolog 
database  with  variables  describing  the  peak  clutter-to-noise  ratio,  the  maximum 
range  of  the  ground  clutter,  and  the  clutter-to-noise  ratio  at  the  maximum  range 
of  the  clutter.  If  weather  is  detected,  a  weather  fact  is  asserted  into  the  database 
with  variables  describing  the  peak  clutter-to-noise  ratio,  the  maximum  range  of 
the  weather,  the  clutter-to-noise  ratio  at  the  maximum  range,  and  the  doppler 
extent  of  the  weather. 

3. 3. 2. 2.2  Determine  Applicable  ECCM 

This  subproblem  determines  radar  control  changes  and  their  expected  impact  on 
detection  probability  for  each  jammer  and  clutter  identification.  The  inputs  are  the 
outputs  of  the  ID  Passive  Interference  and  ID  Active  Interference  subproblems,  as 
well  as  the  list  of  available  ECCM  selected  by  radar  and  u.ser  constraints. 

Jammer  ECCM,  including  frequency  hopping,  sidelobe  canoilfing,  and  sidelobe  blank¬ 
ing  for  narrowband,  CW  sidelobe,  and  asynchronous  pulsed  jammers,  respectively,  are 
enabled  where  appropriate.  Jarnmer-to-noise  ratios  are  adjusted,  corresponding  to  the 
impact  of  the  adaptive  controls. 

Clutter  ECCM,  including  MTI  weights  for  ground  and  weather  clutter,  and  transmit 
polarization  for  weather  clutter,  are  enabled  as  appropriate.  Clutter-to-noise  ratios 
are  adjusted,  corresponding  to  the  impact  of  the  adaptive  controls. 

Determine  Applicable  ECCM  selects  the  controls  in  the  order  indicated  in  Table  8. 
Those  controls  that  have  the  lejist  impact  on  scan  time  and  the  least  SNR  loss  are 
applied  first.  For  each  control  applied,  a  new  estimate  of  the  signal-to-interference 
ratio  is  based  on  user-supplied  nominal  cancellation  values  for  that  control,  parame- 
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Figure  3-9:  ID  Active  Interference  Flow 
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ters  of  the  radar  range  equation  (to  estimate  SNR  for  the  desired  target  cross  section 
and  range),  and  on  JNR  and  CNR  measurements  made  during  CPU  and  CPI2. 

The  numbers  of  looks  required  to  reach  probabilities  of  detection  .1  through  .9  are 
calculated  for  each  beam.  If  the  signal-fco-mterference  ratio  in  a  beam  after  higher 
priority  controls  are  applied  is  still  insufficient  for  achieving  the  desired  Pd  (probabil¬ 
ity  of  detection),  the  last  step  is  to  increase  the  energy  in  the  beam  via  a  noncoherent 
integration  over  a  longer  dwell  time,  with  a  direct  impact  on  scan  time. 

The  benefit  gained  by  dwell-time  increase  with  noncoherent  integration  depends  on 
the  target  flxictuation  characteristics,  the  SIR  per  pulse,  and  the  degree  of  decovrela- 
tion  of  interference  (relative  to  spectral  bandwidth).  These  effects  are  accounted  for 
in  the  A1  rulebase  via  a  table  look-up  of  Pd  versus  number  of  looks  and  SIR  for  a 
Swerling  I  target.  The  spectral  width  of  the  interference  is  estimated  to  determine  the 
effective  decorrelation  time.  For  a  given  estimated  SIR,  the  product  of  the  required 
number  of  independent  looks  to  achieve  a  given  Pd  with  the  de<x>rrelation  time  gives 
the  total  CPIS  dv/ell  lime. 

The  outputs  for  each  beam  are  a  table  of  adaptive  controls  arid  the  numbers  of  looks. 
3. 3. 2. 2. 4  Allocate  Radar  Resources 

This  final  step  produces  the  plan  for  the  next  scan.  The  inputs  to  this  subprobleni 
are  the  outputs  from  Determine  Applicable  ECCM  for  each  beam,  the  Priority  Zones, 
and  the  Quality  Options  Tables.  The  outputs  are  Radar  Control  Parameters. 

The  total  scan  time  required  to  achieve  the  probabilities  of  detection  assigned  to  the 
different  priority  zones  under  each  quality  plan  is  computed,  starting  with  the  first 
plan  and  continuing  until  a  plan  is  reached  that  does  not  exceed  the  desired  scan 
time.  This  is  done  by  adding  (for  each  beam)  interbeam  dead  time,  total  dwell  time 
for  CPI3  as  calculated  using  the  appropriate  probability  of  detection,  CPU  time  if  it 
is  to  be  erformed,  and  CPIS  time  if  it  is  to  be  performed. 

Once  a  an  has  been  selected,  any  remaining  dwell  time  is  allocated  uniformly  across 
all  bean,  in  order  to  use  the  remaining  available  time. 

3. 3. 2. 3  Rulebase  Evolution 

Rulebcise  development  is  an  iterative  process  of  formulating  rules  and  evaluating  their 
impact.  The  well-designed  experiment  will,  therefore,  provide  a  framework  within 
which  rules  can  evolve. 

The  IMRD  differs  from  other  expert  systems  work  in  that  its  expertise  is  a  combi¬ 
nation  of  existing  human  knowledge  (available  at  the  beginning  of  the  contract)  and 
detailed  knowledge  of  how  the  system  behaves  (available  as  the  contract  progressed). 
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Thus,  rulebase  flexibility  was  critical  to  successful  development. 

Both  the  initial  hardware/software  design  and  the  adaptive  control  software  supported 
’terative  development  well,  and  enabled  us  to  model  adaptive  rx)ntrol  expertise  suc¬ 
cessfully.  Section  1.7  summarizes  our  observations  and  findings  during  this  process. 


3.3.3  Software  Development 
3. 3. 3.1  Goals 

IMRD  software  development  goals  included: 

1.  Reuse  of  ACMDSP  design  and  code  where  practical. 

2.  A  system  that  supports  rulebase  evolution. 

3.  Sufficient  IMRD  general’ty  to  support  migration  to  other  radar  environments. 

4.  Software  portability  to  platforms  other  than  the  VAX. 

5.  Stand-alone  operation  for  demonstration  and  testing. 

Reuse  of  existing  work:  The  ACMDSP  made  good  u?e  of  modular  design  principles 
and  was  well  documented.  As  a  result,  its  code  was  accessible  for  reuse.  To  capitalize 
on  this,  oui  initial  design  was  based  on  the  ACMDSP  model  in  which  an  Adaptive 
Controller  spawns  the  Radar  Model  ?s  a  subprocess  and  communicates  with  it  via 
well-defined  interfaces.  This  same  approach  was  taken  with  the  Adaptive  Controller  as. 
main  driver,  spawning  processes  to  handle  VAX/ST-100  and  VAX/HP2il7  interfaces. 
The  main  control  pattern — read  and  process  data  from  each  of  the  beams  in  a  scan, 
assign  control  parameters  for  the  next  scan,  and  send  control  pareuneters  for  the  next 
scan — was  also  maintauned.  As  a  result,  many  of  the  predicates  within  each  of  the 
major  code  blocks  could  be  reused  with  little  or  no  modification. 

Although  the  major  premises  of  the  ACMDSP  were  revised,  approximately  ten  per¬ 
cent  of  the  final  10,000  lines  of  IMRD  code  was  derived  from  existing  software.  Mail¬ 
box  and  process  spawning  code  were  directly  reusable.  Other  portions  served  as  a 
starting  point  and  saved  significant  development  time  on  our  part. 

Rulebase  evolution:  The  IMRD  schedule  mandated  that  hardware  and  software  be 
developed  in  parallel.  However,  characteristics  of  the  interferences  identified,  equip¬ 
ment  tolerances,  and  the  impact  of  adaptive  control  applied  were  understood  only 
after  closed  loop  operation  was  achieved.  Hence,  much  of  the  rulebase  development 
was  done  after  major  portions  of  the  software  were  written. 
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This  type  of  development  was  supported  by  isolating  expert  system  subpioblems 
within  separate  predicates.  The  similarity  between  Prolog  predicates  and  English- 
language  rules  further  supports  modification  and  expansion. 

Other  radar  environments:  Ideally,  the  IMRD  framework  and  perhaps  even  the 
specific  expertise  are  applicable  to  other  hardware  environments.  In  particular,  the 
concept  of  a  3-CPI  beam  dwell  and  the  Adaptive  Control  AI  subproblem  decomposi¬ 
tion  should  transfer. 

Additionally,  Adaptive  Controller  data  structures  include  radar-specific  data  (Radar 
Design  Parameters),  environment-specific  data  (Radar  Environment  Parameters),  in¬ 
put  from  the  radar  to  the  Adaptive  Controller  (Beam  Scan  Data),  and  data  output 
from  the  Adaptive  Controller  to  the  radar  (Radar  Control  Parameters).  These  can 
be  tailored  to  other  software  and  radar  environments.  They  also  proved  useful  during 
system  development  since  values  for  a  number  of  the  radar-specific  constants  were 
not  known  until  closed  loop  operation  had  been  attained. 

Software  portability:  Software  portability  is  critical  to  avoid  restricting  this  work  to 
a  VAX  host.  VAX  system  services  are  used  to  spawn  subprocesses,  for  interprocess 
communication,  and  for  interfacing  to  the  radar  control  software,  but  calls  to  sys¬ 
tem  services  are  isolated  within  the  spawned  subprocesses  and  within  specific  Pascal 
procedures.  The  Prolog  code  could  be  used  on  another  host  operating  system  with¬ 
out  change.  The  system  service  calls  and  spawned  process  code  would  need  to  be 
modified. 

Stand-alone  operation:  Stand-alone  operation  of  the  IMRD  software  was  neces¬ 
sary  for  both  system  development  and  rulebase  evolution.  The  interface  between  the 
Adaptive  Controller  and  rauar  is  through  VMS  scan  and  control  mailboxes.  The 
FRDE  can  send  recorded  scan  data  to  the  scan  mailbox  and  retrieve  control  parame¬ 
ters  from  a  control  mailbox  was  built  for  stand-alone  operation.  As  a  result,  we  could 
test  the  Adaptive  Controller  before  hardware/software  integration  permitted  closed 
loop  operation  of  the  entire  system  and  rulebase  development  using  taped  data  could 
proceed  in  parallel  with  hardware/software  integration. 

3. 3.3. 2  Implementation 

Adaptive  control  software  consists  of  a  Main  Adaptive  Control  process  which  perfornrs 
system  initialization  and  spawns  the  appropriate  subprocesses  to  perform  communi¬ 
cation  tasks.  At  initialization,  the  Main  Adaptive  Control  process  reads  in  .figura¬ 
tion  options,  one  of  which  tells  the  process  whether  the  system  should  run  m  Radar 
Interface  or  in  Stand-Alone  configuration. 
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Radar  Interface  configuration:  Under  this  option,  inputs  axe  received  from  the 
radar  via  the  ST- 100,  and  Radar  Control  Parameters  are  distributed  to  the  radar  via 
the  HP2117.  The  three  processes  used  under  Radar  Interface  configuration  are  the 
Main  process,  the  ST-100  Host  process,  and  the  Radar  Controller  Interface  (RC-IF) 
process,  as  shown  in  Figure  3-10.  Communication  among  the  processes  is  through 
VMS  mailboxes. 

Stand-Alone  configuration:  The  Adaptive  Controller  can  be  used  in  Stand-Alone 
configuration  to  test  the  system  without  requiring  live  radar  inputs.  The  FRDE 
process  is  spawned  to  handle  communications  tasks  with  the  Main  process,  as  shown 
in  Figure  3-11.  Beam  Scan  Data  sent  to  Main  is  retrieved  from  an  ASCII  file  rather 
than  from  the  ST-100.  Radar  Control  Parameters  are  sent  by  the  Main  process  to 
the  FRDE  rather  than  to  the  RCJF  process  which  would  normally  forward  them  to 
the  HP2117.  Both  of  these  functions  are  accomphshed  via  the  same  VMS  mailboxes 
used  in  the  Radar  Interface  configuration. 

3. 3.3. 2.1  Inputs 

Inputs  to  the  Adaptive  Controller  are  Beam  Scan  Data,  which  is  received  from  the  ST- 
100  signal  processing  software  via  the  VAX/ST- 100  interface.  These  inputs  consist  of 
one  Pasci  1  record  for  each  beam  in  the  surveillance  region,  and  contain  results  after 
signal  pro  ;essing  of  passive  and  active  radar  dwells  in  the  most  recent  scan. 

Beam  Sea  i  Data  is  used  by  the  subproblems,  ID  Passive  Interference  and  ID  Active 
Interferen<  e,  to  determine  what,  if  any,  interferences  are  present. 

3.3.3. 2.2  Process  Descriptions 

Main  Adaptive  Control:  The  Adaptive  Controller  consists  of  the  following  software 
modules,  >/ith  interrelations  as  shown  in  Figure  2-4: 

1.  A  User  Interface  allows  the  user  to  specify  default  input  parameters  or  to  enter 
th<  parameters  interactively. 

2.  Ar*  AI  Engine  assesses  the  current  environment  and  selects  radar  control  op¬ 
tions  for  the  next  scan. 

3.  An  AI  Duplay  displays  user-selected  parameters  on  the  screen  and/or  saves 
them  in  a  file. 

The  AI  Engine  is  further  divided  into  the  four  subproblems  discussed  in  Sec¬ 
tion  3. 3. 2.2:  ID  Passive  Interference,  ID  Active  Interference,  Determine  Applicable 
ECCM,  and  Allocate  Radar  Resources. 


Figure  3-10:  Radar  Iiilerface  Software  Organization 
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Figure  3-11:  Stand-Alone  Software  Configuration 

The  Main  process  spawns  the  two  subprocesses,  as  shown  in  Figure  3-10.  The  ST- 
100  Host  process  handles  communications  between  the  signal  processing  software 
residing  on  the  ST- 100  and  the  other  VAX  processes.  The  RCJF  process  handles 
communcations  between  the  HP2117  and  the  other  VAX  processes. 

VMS  mailboxes  and  common  event  flags  are  used  for  VAX  interprocess  communica¬ 
tion.  Common  event  flags  are  used  for  interprocess  synchronization.  A  scan  mailbox 
is  used  for  communication  between  the  Main  process  and  the  ST-100  Host  process.  A 
control  mailbox  is  used  for  conmiunication  between  the  Main  process  and  the  RC-IF 
process.  This  allows  the  Main  process  to  remain  independent  of  the  processes  that 
interface  to  external  equipment. 

ST-100  Host  process:  The  primary  responsibility  of  the  ST-100  Host  process  is  to 
communicate  with  the  ST- 100  signal  processing  software.  This  includes  download¬ 
ing  Array  Processor  Code  Language  (APCL)  process  code,  passing  synchronization 
semaphores  from  the  adaptive  control  and  radar  control  software,  and  uploading  the 
calculated  Beam  Scan  Data  from  the  ST-100  to  the  VAX. 

The  ST- 100  Host  process  downloads  signal  processing  software  to  the  ST- 100  and 
performs  ST- 100  initialization  routines,  as  described  in  the  Array  Processor  Executive 
User’s  Guide.  VMS  common  event  flags  are  then  used  to  synchronize  the  radar  cont'-ol 
and  the  signal  processing  software.  RCJF  sets  an  event  flag  to  signal  completion  of 
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CPI3.  This  information  ’s  forwarded  to  the  signal  processing  software  via  ST-100 
semaphores.  Another  ST- 100  semaphore  signals  that  the  ST- 100  is  ready  to  receive 
CPU  data.  The  ST- 100  Host  process  then  uses  an  event  flag  to  tell  the  RC-IF  process 
that  the  ST- 100  is  ready  to  start  CPU.  In  this  way,  each  beam  is  synchronized, 

Other  ST- 100  semaphores  synchronize  uploading  the  Beam  Scan  Data  from  the  ST- 
100  as  the  data  is  calculated.  Once  a  complete  Beam  Scan  Data  record  is  assembled, 
the  process  uploads  the  record  to  the  Main  process  via  the  scan  mailbox.  This  mailbox 
is  also  used  at  the  end  of  each  scan  to  inform  the  ST- 100  Host  proce-ss  whether  to 
terminate  or  to  initiate  another  scan.  Another  event  flag  is  set  by  the  ST-100  Host 
process  to  tell  the  Main  process  that  its  termination  procedures  are  complete. 

Radar  Controller  Interface  process:  The  RC_IF  process  controls  communications 
between  the  HP2117  and  the  VAX.  This  consists  of  passing  Radar  Control  Parameters 
and  synchronization  semaphores  to  the  HP2117. 

The  primary  RC_IF  process  responsibility  is  to  receive  Radar  Control  Parameters 
from  the  Main  process  via  the  control  mailbox  and  forward  them  to  the  HP2117 
Radar  Controller.  This  mailbox  is  also  used  at  the  end  of  each  scan  to  inform  RC_IF 
whether  to  terminate  or  to  initiate  the  next  scan.  Two  event  flags  synchronize  beam 
timing  between  the  ST- 100  and  the  Radar  Controller.  Two  additional  event  flags  are 
sent  by  RC  JF  to  Main  to  signal  process  initiation  and  process  termination. 

Flexible  Radar  Data  Executive:  The  FRDE  process  takes  the  place  of  the  ST- 100 
Host  and  RC  JF  processes  when  the  system  executes  in  Stand  Alone  configuration. 
The  FRDE  opens  the  file,  bsam^can_data,  and  reads  Beam  Scan  Data  for  one  scan. 
This  file  has  the  same  format  as  that  produced  when  using  the  AI  Output  Parameter, 
diagnostic-Output  (beamjscan.data),  to  collect  Beam  Scan  Data.  The  file  can  contain 
data  for  any  number  of  beams.  The  Beam  Scan  Data  is  then  sent  on  a  beam-by-beam 
basis  to  the  Main  process  via  the  scan  mailbox.  The  FRDE  also  receives  the  Radar 
Control  Parameters  from  the  Main  process  \ia  the  control  mai'box.  Both  of  these 
functions  are  accomplished  via  the  same  VMS  scan  and  control  mailboxes  used  in 
the  Radar  Interface  configuration.  Both  the  ST- 100  Host  and  the  RCJF  termination 
messages  are  sent  to  the  FRDE.  The  FRDE  then  sets  both  termination  complete 
event  flags  to  signal  process  termination. 


3. 3. 3. 2. 3  Outputs 

Outputs  from  the  Adaptive  Controller  are  sent  to  the  HP2117  Radar  Controller  in 
tne  form  of  Radar  Control  Parameters.  These  consist  of  one  Pascal  record  for  each 
beam  in  the  surveillance  region,  specifying  radar  operating  characteristics  for  the  next 


scan. 
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The  Allocate  Radar  Resources  subproblem  produces  the  Radar  Control  Pararreter 
outputs  to  be  used  for  the  next  scan.  Radar  Control  Parameters  for  the  first  scan 
are  read  from  a  file  at  system  startup.  Subsequent  Radar  Control  Parameters  are 
generated  by  the  Adaptive  Controller. 

User- requested  output  information  is  sent  to  the  user’s  terminal  or  to  files,  as  specified 
by  the  AI  Output  Parameters. 

3.3.4  Parameterization 

The  AI  testbed  can  be  configured  to  accommodate  a  variety  of  radar  environments 
through  Radar  Design  Parameters  and  Radar  Environment  Parameters.  The  first 
category  contains  parameters  related  to  the  specific  radar,  the  second  to  the  radar 
environment.  This  data  is  read  from  files  during  system  initialiMtion.  The  files  can 
be  modified  by  using  any  standard  text  editor. 

Radar  Design  Parameters  define  the  operating  characteristics  o!  the  physical  radar 
with  which  the  Adaptive  Controller  interfaces.  The  parameters  are  read  from  files 
at  system  initialization  and  may  be  modified  olf-line  by  using  a  text  editor.  They 
include  information  such  as  azimuth  limits  and  the  pulse  repetition  interval. 

Collecting  these  parameters  in  one  data  structure  makes  any  assumptions  about  the 
radar  explicit  and  visible.  We  have  had  occasion  to  change  these  parameters  during 
operation  and  appreciated  not  being  required  to  locate  embedded  constants  or  to 
recompile  the  system.  For  instance,  the  PRi  was  modified  several  times  in  order  to 
experiment  with  performance  improvement.  This  was  easily  accomplished  by  editing 
the  edm_radar_design.dat  file  and  setting  the  new  PRI  value.  Appendix  A. 3  describes 
this  data  structure. 

Radar  Environment  Parameters  describe  the  thermal  noise  received  by  the  radar  as 
well  as  the  ground  and  weather  clutter  maps  to  be  used  in  the  ID  Active  Interference 
subproblem.  The  pjwameters  are  read  from  files  at  system  initialization  and  may  be 
modified  off-line  by  using  a  text  editor.  Appendix  B.3  describes  this  data  structure. 


Language 

Usage 

Prolog 

•  The  main  driver,  calling  routines  in  Pascal  as  necessary. 
The  foreign  language  interface  assigns  a  link  between 
a  Prolog  predicate  and  a  Pascal  procedure  or  function. 
When  the  predicate  is  invoked,  control  is  transfered  to 
the  assigned  routine 

•  Rulebases.  These  are  accessable  for  modification  and 
evolution 

•  Inferencing.  Prolog  backtracking  made  this  function 
transparent 

•  Most  of  the  on-line  user  interface.  Prolog  was  selected 
here  so  an  to  use  portions  of  the  Motorola  code 

•  Priority  zone  data  structure.  Prolog  was  selected  liere  so 
as  to  use  portions  of  the  Motorola  code 

•  Global  data  structures  which  organize  the  types  of  infor¬ 
mation  needed 

•  Computation 

•  Mailbox  utilities  through  which  the  Adaptive  Controller 
interfaces  with  the  remainder  of  the  IMRD  system 

•  Subprocess  spawning  and  control 

EQEIBM 

•  The  PC.JF  process  which  supports  communication  be¬ 
tween  the  VAX  and  the  HP2117F 

•  The  ST- 100  host  process  which  supports  communication 
between  the  VAX  and  the  ST- 100 

Table  7:  Language  Select’on 
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Interference 

MLC 

(Growth) 

SLB 

SLC 

(Growth) 

Adaptive 

Polariz 

MTI 

Frequency 

Change 

Adjust 

Dwell 

Time 

NB  CV/  mainlobe 

2 

1 

3 

NB  CW  sidelobe 

2 

1 

3 

WB  CW  mainlobe 

1 

2 

WB  CW  sidelobe 

1 

2 

NB  ASP  mainlobe 

1 

2 

NB  ASP  sidelobe 

2 

1 

2 

WB  ASP  mainlobe 

1 

WB  ASP  sidelobe 

1 

2 

NB  unknown 

1 

2 

WB  unknown 

1 

Ground  clutter 

1 

Rain  clutter 

1 

2 

3 

Table  8:  Applicable  Adaptive  Controls  and  Order  of  Application 
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3.4  Radar  Control 

Hadar  control  and  timing  synchronization  is  performed  using  a  combination  of 
HP2117  software  and  special-purpose  hardware.  The  following  sections  summarize 
the  function  and  implementation  of  IMRD  control  and  timing  functions. 

3.4.1  Requirements 

The  Radar  Controller  performs  the  following  functions: 

1.  Initialize  all  the  radar  hardware  (i.e.,  antenna  controller,  Tx/Rx  frequency,  MTI 
weights,  video  blanker,  sidelobe  blanker,  and  3-CPI  circuit. 

2.  Establish  a  communications  channel  to  the  VAX  via  the  IEEE-488  bus  port. 

3.  Prior  to  each  scan,  receive  inputs  from  the  VAX  AI  processor  specifying  the 
parameters  for  that  scan. 

4.  Verify  that  the  desired  Radar  Control  Parameters  are  consistent  with  RLSF 
equipment  capabilities.  If  not,  alert  the  operator  of  the  inconsistency.  Abort 
the  process  for  that  beam  dwell  if  the  inconsistency  is  fatal. 

5.  Encode  the  parameters  from  the  AI  processor  into  hardware  contunands  that 
are  recognizable  by  the  RLSF  hardware. 

6.  Send  the  encoded  hardware  commands  to  the  RLSF  equipment  during  the  dead 
time  interval  prior  to  the  beam  dwell.  During  this  time,  the  radar  will  be  turned 
off. 

7.  Synchronize  the  radar  operation  by  properly  timing  control  signals  sent  to  the 
real-time  processing  and  control  equipment. 

3.4.2  Variables  and  Interfaces 

Table  9  lists  the  inputs  from  the  VAX  to  the  Radar  Controller  via  the  IEEE-488  bus. 
One  set  of  these  controls  is  sent  for  each  beam  in  the  scan.  The  index  is  the  order  in 
which  the  components  are  sent  over  the  interface.  Several  of  the  parameters  passed 
for  each  beam  are  not  currently  set  by  the  adaptive  control  software.  Their  function 
is  to  allow  future  growth  of  the  control  scheme. 

Table  10  lists  the  semaphores  that  are  sent  from  the  HP2117  to  control  CPU  and 
CP12  processing  in  the  ST- 100.  Table  11  lists  the  mechanisms  which  control  the 
physical  hardware. 
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Index 

Parameter 

Description 

1 

last_beam 

Flag  indicating  last  beam  of  scan  (1  =  last) 

2 

face-indx 

Pedestal  azimuth 

3 

beam-azJn 

Beam  azimuth  offset  in  millidegrees  relative  to 
-45  degrees  from  pedestal  azimuth 

4 

elJndx 

Pedestal  elevation  index  (not  used) 

5 

freq 

Frequency  index  (0-7) 

6 

s-blank 

Sidelobe  blanker  flag  (1  =  blanking  on) 

7 

8_cancel 

Sidelobe  canceller  flag  (1  =  canceller  on) 

8 

cfar 

CFAR,  value  (not  used) 

9 

pri 

PRI  value  (not  used) 

10 

pulse_dur 

Transmit  pulse  duration  (not  used) 

11 

pulse_bw 

Transmit  pulse  bandwidth  (not  used) 

12 

tx-polar 

Transmit  polarization  index 

13 

rx.polar 

Receive  polarization  index  (not  used) 

14 

weights 

MTI  weight  set  index  (1-64) 

15 

dwelLtim 

CPI3  dwell  period  (in  /zsec) 

16 

numJooks 

Number  of  CPI3  dwells 

17 

paj)sive_on 

Disables  CPU  (not  used) 

18 

active^on 

Disables  CPI2  (not  used) 

Table  9:  Radar  Control  Inputs 


Value 

Description 

2 

4 

998 

999 

End  of  CPI2  processing 
Start  CPU 

Terminate  processing 
End  of  scan 

Table  10:  Control  Semaphores 


66 


Description 

Destination 

Interface 

Pedestal  azimuth 

Beam  azimuth 

Transmit  polarization 
Antenna  frequency 
C-Band  LO  frequency 
MTI  weights 

Sidelobe  blanker  enable 
Video  blanker  enable 
3-CPI  enable 

C-Band  DCU 

C-Band  DCU 

C-Band  DCU 

C-Band  DCU 

C-Band  frequency  synthesizer 
PTF 

Sidelobe  bl2Uiker 

Video  blanker 

3-CPI  circuit 

DCU 

DCU 

DCU 

DCU 

IEEE-488 

Existing  parallel 
Static  bit 

Static  bit 

Static  bit 

Table  11:  Radar  Control  Outputs 


3.4.3  Controller  Design 

The  Hadar  Controller  consists  of  a  control  function  is  performed  by  software 

resident  on  the  HP2117,  and  radar  timing  and  synchronization  which  is  performed 
in  hardware  by  the  3-CPI  circuit  and  the  C-Band  Range  Tracker.  The  system  block 
diagram  (Figure  2-3)  illustrates  the  control  and  timing  functions,  and  the  relationship 
to  the  radar  and  processing  equipments.  A  description  of  the  evolution  of  the  design 
of  the  radar  control  functions  and  the  ultimate  implementation  follows. 

3.4.3. 1  Software  Design  Evolution 

The  following  considerations  influenced  the  radar  control  software  design. 

Synchronization  and  communication  of  the  processing  elements  and  the  radar  system 
was  perhaps  the  biggest  consideration  in  designing  the  Radar  Controller.  Raw  radar 
data  must  be  provided  to  the  array  processor  for  the  three  different  dwell  periods 
(CPIs),  Radar  Control  Parameters  must  be  received  from  the  VAX,  and  control  must 
be  provided  for  the  radsir  by  the  controller. 

Controlling  the  radsu:  timing  by  generating  strobes  for  the  transmitter,  receiver,  data 
transfer,  and  display  control  functions  was  achievable  by  several  methods.  The  eval¬ 
uation  factors  in  the  selection  of  timing  control  were  the  ease  of  interface  to  the 
Rad.-'r  Controller,  the  precision  which  was  required  for  the  timing  signals,  and  the 
requirement  of  maximum  scan  time. 


3. 4.3. 2  Radar  Controller  Platform  Selection 
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Potential  hosts  lor  the  radar  control  function  included  the  VAX,  a  special-purpose 
hardware  controller,  an  IBM-compatible  personal  computer,  and  the  HP2117. 

Real-time  processing  limitations  and  lack  of  existing  interfaces  to  the  radar  system 
eliminated  the  VAX.  A  dedicated  special-purpose  hardware  controller  had  the  ad¬ 
vantage  of  the  most  precise  control  timing,  but  was  eliminated  due  to  the  lack  of 
existing  interfaces  to  any  of  the  RLSF  equipment  and  to  the  high  cost  involved  in  its 
design  and  construction.  The  personal  computer  approach  was  also  discarded  because 
there  were  no  existing  interfaces  between  it  and  the  RLSF  equipment.  The  HP2117 
remained  the  logical  candidate  to  host  the  radar  control  function. 

The  HP2117  has  interfaces  with  much  of  the  required  RLSF  equipment  (e.g.,  C-Band 
antenna  controller,  C-Band  LO,  VAX,  and  PTF),  yet  was  not  well  suited  to  timing 
synchronization  control  at  the  level  required  by  the  radar  system.  For  the  precisely- 
timed  radar  operation,  the  existing  C-Band  range  tracker  was  used  in  conjunction 
with  the  3-CPI  circuit  which  was  designed  and  built  under  this  contract.  Interfaces 
to  the  sidelobe  blanker,  video  blanker,  and  the  3-CPI  were  added  using  static  register 
bits  from  the  HP2117.  These  bits  are  toggled  during  execution  to  enable  or  di&able 
the  blankers  or  the  3-CPI  circuit. 


3.4.S.3  VAX/HP21i7  Communications  and  Synchronization 

The  major  driver  for  selecting  an  interface  between  the  VAX  and  the  HP2117  con¬ 
troller  was  the  quantity  of  data  that  must  be  transferred  for  each  scan.  The  ex¬ 
isting  IEEE-488  bus  was  selected  to  transfer  the  Radar  Control  Parameters  to  the 
Radar  Controller  because  it  has  a  significant  bandwidth  advantage  over  a  serial  link. 
Synchronization  messages  ware  also  p£issed  over  the  IEEE-488  bus  to  minimize  the 
amount  of  interfaces  present  between  subsystems  and  the  amount  of  software  neces¬ 
sary  to  maintain  each  interface. 

Four  messages  (semaphores)  are  passed  from  the  VAX  to  the  HP2117  during  the 
operation  of  the  system,  as  described  in  Table  10.  A  graphic  view  of  process  control 
timeline  is  shown  in  Figure  3-12.  The  VAX  sends  a  message  to  the  HP2117  indicating 
that  it  is  ready  for  an  event  (such  as  end-of-scan)  to  occur.  The  VAX  will  not 
continue  processing  until  that  message  has  been  physically  read  by  the  HP.  Using  this 
synchronization  technique,  the  VAX  will  never  get  ahead  of  the  HP2117  controller. 
The  process  is  terminated  by  passing  a  message  “998”  to  the  HP2117  at  the  beginning 
of  a  scan.  This  signals  the  HP2117  to  terminate  the  link  to  the  VAX  and  to  end  its 
execution. 


3. 4. 3. 4  Software 

A  high-level  flowchart  of  the  rad2u-  control  software  resident  on  the  HP2117  is  shown 
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Figure  3-12:  Process  Control  Timeline 
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in  Figure  3-13. 

The  radar  cx»ntrol  software  is  organized  in  a  modular  structure  with  three  separate 
levels  of  control.  The  top  level  (RUNAf)  establishes  communication  with  the  VAX  and 
begins  operating  the  control  software.  The  second  level  contains  the  main  processing 
and  synchronization  functions  (CTLAI,  CPI1_2,  LASTGPI)  which  perform  the  radar 
control  and  tinring  function.  The  third  level  of  software  contains  the  individual  device 
control  routines  (DCU.  CONTROL,  C-FREQ,  RECVI^UB,  PTFSUB)  which  send 
the  actual  controls  to  perform  the  radar  control.  A  call  diagram  is  shown  in  Figure  3- 
14. 

Functional!}',  the  process  is  initiated  by  RUNAI  which  initializes  the  HP2117  to  VAX 
IEEE-488  bus  interface  and  calls  CTLAI.  The  CTLAI  is  the  main  control  routine  for 
the  process.  The  CTLAI  routine  first  initializes  the  antenna  position  for  all  beams, 
the  receiver  frequency,  and  reads  in  the  PTF  weight  table  for  all  weight  indices.  After 
receiving  the  first  end-of-scan  semaphore  (semaphore  =  999),  the  processing  begins. 
For  each  scan,  720  words  of  data  (40  beams/scan  *  18  parameters/beam)  are  received 
from  the  VAX  via  the  IEEE-488  bus.  (The  parameters  received  for  each  beam  are 
given  in  Table  9.)  Those  not  implemented  by  the  radar  control  software  are  included 
for  future  growth  of  the  control  scheme. 

After  all  720  parameters  are  received,  CTLAI  enters  a  beam  loop  which  is  executed 
40  times  (or  until  a  last-beam  flag  is  encotintered).  The  first  operation  in  the  beam 
loop  is  to  check  the  frequency  index  for  this  beam.  If  it  is  different  than  the  last 
beam,  the  receive  frequency  is  changed.  The  process  then  waits  for  an  “end  of  CPI3” 
semaphore  (semaphore  =  2)  and  verifies  all  received  parameters  foi  this  beam.  If 
all  are  within  limits,  a  “start  CPU”  semaphore  is  expected  (semaphore  =  4)  which 
initiates  the  antenna  to  be  instructed  to  the  proper  position  and  for  CPU  to  begin. 
Following  the  completion  of  CPI  1  and  2,  the  PTF  is  loaded  with  the  selected  weights 
and  CPIS  is  executed.  This  is  the  end  of  the  beam  loop. 

The  user  can  request  that  control  parameters  received  from  the  VAX  and  implemented 
on  the  radar  be  saved  in  a  file.  This  option  is  intended  to  assist  the  operator  in 
post  experiment  analysis  of  controller  actions  taken  in  response  to  the  environment 
and  to  aid  in  debugging  the  communications  link,  if  necessary.  Writing  the  control 
parameters  to  a  file  slows  the  control  software  and  is  not  normally  used.  The  software 
also  allows  the  user  to  specify  the  mechanical  pedestal  position  which  is  the  center  of 
the  scan  volume.  The  VAX  software  commands  the  antenna  position  relative  to  the 
user-selected  scan  center  angle. 

3. 4. 3. 5  Radar  Control  Timing  Signals 

We  used  as  many  of  the  existing  radar  timing  signals  as  possible  in  order  to  preserve 


F'igurc  3-13:  Radar  Control  Software  Flowchart 
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Figure  3-14:  Radar  Control  Software  Call  Diagram 


the  relative  timing  and  to  minimize  the  amount  of  additioned  hardware  and  software 
required  to  generate  the  signals.  The  approach  taken  wa^  to  use  the  free-running 
PRF  strobe  from  the  existing  radar  control  and  timing  unit  (RTCU)  equipment  to 
trigger  all  events  in  the  radar.  The  C-Band  range  tracker  was  employed  to  generate 
the  transmitter  timing  signals,  the  exciter  strobe  (WFG  trigger),  the  antenna  phase 
shifter  timing  gate  (PSTG)  signal,  and  the  range  zero  trigger  for  the  display  The 
timing  of  the  signals  generated  in  the  range  tracker  relative  to  the  PRF  trigger  is 
downloaded  during  the  set-up  of  the  experiment  and  does  not  change  during  the 
experiment.  The  existing  AIGATES  software  downloads  a  set  of  prestored  parameters 
to  the  range  tracker.  Additional  hardware  gates  some  of  the  timing  signals  for  proper 
operation  of  the  AI  software.  The  ESP,  therefore,  requires  that  the  transmitter  be 
off  during  CPU  and  on  during  CPI2  and  CPIS.  The  3-CPI  circuit  performs  the 
function  of  gating  the  transmitter  and  WFG  trigger  during  CPU.  Additionally,  the 
3-CPI  synchronizes  radar  data  transfer  to  the  ST-100  by  gating  the  PRF  strobe  to 
the  header  generator  which  is  used  to  initiate  transfers  to  the  ST- 100.  A  macro- level 
timing  diagram  is  given  in  Figure  3-15. 

When  the  ENABLE  signal  from  the  HP2117  static  register  control  bit  is  inactive 
(low),  no  strobes  are  generated  to  the  Dill  or  to  the  WFG,  and  no  RF  gates  are 
generated  to  the  transmitter.  When  ENABLE  transitions  to  the  active  slate  (high, 
controlled  by  the  radar  control  software).  !6  replicas  of  the  PRF  strobe  are  sent  to 
the  DUI,  allowing  16  PRIs  of  passive  dwell  (no  transmit  signal)  data  to  be  sent  to  the 
ST-100.  Following  these  16  passive  dwells,  timing  signals  are  sent  to  the  DHL  WT'C, 
and  RF  gate  to  allow  transmission  of  waveforms  and  transfer  of  data  to  the  ST- 100 
until  the  ENABLE  bit  is  again  placed  in  the  inactive  state.  This  provides  an  active 
dwell  (transmitter  on)  equal  to  the  duration  the  ENABLE  bit  is  high  minus  the  16 
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Figure  3-15:  Macro- Level  3-CPI  Circuit  Timing 

PRI  pa^isivc  dwell.  The  length  of  CPIS  is  controlled  by  the  radar  control  .software  by 
maintaining  the  ENABLE  bit  in  the  active  state  for  the  amount  of  time  pa.''8cd  from 
the  VAX. 


3. 4.3. 6  Radar  Configuration 

Certain  radar  parameters  such  as  the  waveform  characteristics,  PRF,  and  A/D  clock 
rate  are  not  presently  controllable  by  the  radar  control  software.  The  primary  reason 
is  that  the  amount  of  effort  required  to  make  these  parameters  adaptive  would  have 
detracted  from  the  efforts  necessary  to  achieve  the  program  goals.  Control  of  these 
parameters  was,  therefore,  not  made  a  part  of  the  experimental  set-up  and  was  not 
integrated  into  the  run-time  radar  control  software.  The  existing  SPLEX  software  is 
used  to  configure  the  radar  PRP\  the  WFG  parameters,  the  radar  data  rate,  and  the 
receiver  data  path  selection  prior  to  the  experiment.  These  settings  remain  constant 
during  the  experiment. 

3. 4. 3. 7  Video  Blanking 

Due  to  the  sequential  processing  of  data  from  three  CPIs,  and  the  fact  that  the  desired 
countermeasures  were  implemented  only  during  CP13  (the  detection  waveform),  the 
display  (UPA  62)  need«*d  to  be  blanked  during  all  but  CPI3.  Initial  attempts  were 
made  a*  gating  the  range  zero  pulse  to  the  PPI  as  a  means  of  blanking  the  display.  The 
re.sult  was  a  loss  of  the  range  reference  during  the  first  several  dwells  of  the  detection 
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waveform,  and  a  blurry  display  of  uncancelled  target  and  clutter  returns.  The  final 
implementation,  which  resulted  in  a  very  clear  display  and  timely  gating  of  the  video 
signal,  was  to  use  the  bias  control  input  on  the  final  video  amp  to  gate  the  signal.  By 
placing  the  bias  control  in  an  inactive  state  except  during  the  detection  waveform, 
the  PPI  is  blank  during  dead  time  and  environmental  assessment  periods.  Only  the 
processed  result  of  the  A!  controllc'd  radar,  with  the  appropriate  countermeasures 
implemented,  is  displayed. 
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3.5  Display 

3.5.1  Requirements 

The  IMRD  top-level  display  requirements  were: 

1.  Display  all  processed  real  targets  and  environmental  interference  over  the  se¬ 
lected  scan  volume  in  real-time  at  a  bandwidth  commensurate  with  that  for  the 
radar  video. 

2.  Provide  a  believable  visual  indication  of  target  detectability  with  specific  cross 
sections,  as  required  by  the  SOW. 

3.  Maxinuze  credibility  by  basing  target  detection  indicator  on  real-world  (as  op¬ 
posed  to  computed  or  simulated)  outputs. 

4.  Use  existing  equipment  to  the  maximum  extent  to  reduce  co.^ts. 

5.  Display  current  .M  status  for  each  beam. 

The  first  four  are  detection  display  requirements;  the  fifth  is  an  AI  display  require¬ 
ment. 

Several  options  were  evaluated,  including; 

1.  Adapt  the  ACMDSP  simulation  to  display  detections,  detection  range  contour, 
and  AI  status  on  a  computer  monitor. 

2.  Develop  a  new  VAX-driven  display. 

3.  Use  a  UPA-62  PPI  for  real-time  status  display  and  a  separate  VAX-driven  Telc- 
tronics  display  to  show  detection  performance  and  AI  status.  UPA-62  display 
input  could  be  driven  by  either  the  dedicated  hardware  output  data  or  the 
ST-100  output  data  via  the  ST-100  to  PPI  (SPI)  interface. 

4.  Use  UPA-62  PPI  to  display  detections  and  detection  perfornnance,  and  a  sepa¬ 
rate  VAX-driven  display  to  show  AI  status. 

Option  (1)  would  have  required  extensive  rework  of  the  existing  ACMDSP  code  to 
enable  displaying  real-virorld  data-  especially  for  clutter,  which  would  consist  of  sev¬ 
eral  individual  reports  (one  for  each  cell)  instead  of  variables  defining  boundaries  of 
the  clutter  as  in  the  ACMDSP.  Also,  the  detection  contour  performance  indicator 
is  highly  suspect  since  it  is  based  on  a  top-level  software  simulation  as  well  as  on 
knowledge  of  the  scenario  being  simulated  and,  hence,  was  impractical  for  a  credible 
real-world  display.  It  is  unlikely  that  it  could  have  performed  in  real-time. 

Option  (2)  would  have  required  extensive  new  software  coding  and  consumed  a  dis¬ 
proportionate  amount  of  conLr’*et  resources.  Moreover,  it  is  doubtful  whether  it  would 
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have  been  able  to  keep  up  with  all  detection  reports  in  real  time.  Therefore,  require¬ 
ments  (1)  and  (4)  would  probably  not  have  been  met. 

The  UPA-62  options  were  preferred  from'ooth  a  cost  and  a  performance  standpoint: 
interfaces  already  existed  from  either  the  dedicated  digital  processing  chain  or  the  SPI 
interf2w;e;  furthermore,  they  supported  the  bandwidths  of  the  video  data  (nominally  1 
MHz).  The  AI  status  display  could  then  easily  be  handled  by  a  VAX-driven  graphics 
terminal  since  the  bandwidth  requirements  are  much  lower. 

The  performance  indicator  display  distinguishes  options  (3)  from  (4).  Within  options 
(3)  and  (4)  two  sub-options  for  graphical  indication  of  performance  were  considered: 

a.  a  detection  range  performance  indicator,  and 

b.  a  minimum  detectable  signal  performance  indicator. 

Generating  the  detection  range  contour  option  requires  a  software  simulation  of  at 
least  portions  of  the  entire  signal  processing  string  to  generate,  and  hence  lacks  cred¬ 
ibility.  Also,  if  detection  is  clutter-limited,  more  than  one  detection  range  value  may 
be  necessary  if  there  is  significant  variance  in  interference  characteristics  in  range,  e.g. 
a  transition  from  severe  ground  clutter  at  close  ranges  (with  possibly  a  low  detection 
range)  to  in  the  clear  at  further  ranges  (with  possibly  a  large  detection  range).  In 
lieu  of  the  detection  range  display,  the  PPI  display  shown  in  Figure  3-16  (Option  4b) 
was  selected. 

We  determined  that  the  most  credible  demonstration  would  use  the  UPA-62  to  dis¬ 
play  returns  from  the  adapted  waveform  and  a  separate  VAX  display  to  track  Al 
performance  status. 

3.5.2  Detection  Display 

The  advantages  of  the  UPA-62  detection  display  are 

1  It  does  not  rely  on  simulations  of  the  signal  processor  to  display  true  perfor¬ 
mance. 

2.  It  enables  the  display  of  target  detectability  in  selected  range  regions  for  each 
beam  and  thus  better  accounts  for  variations  in  detectability  versus  interference 
background  variations  within  a  beam. 

3.  It  provides  relative  performance  advantages  in  dB  of  Al  adaptivity,  providing  a 
bottom-line  assessment  of  A I  for  the  demonstration. 

4.  We  believed  it  unlikely  that  the  VAX  could  display  real-world  data  in  real-time. 


Targets  of 
Opportunity 


Figure  3  10:  Real-Time  Detcrtion  and  Performance  Display 
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As  shown  in  Figure  3-16,  the  display  haa  two  concentric  rings  indicating  two  constant- 
range  targets  in  each  beam  with  varying  cross  sections  controlled  from  the  SPLEX  T 
menu.  The  range  of  the  rings  is  selected  by  the  operator  for  positioning,  as  desired, 
within  different  interference  zones.  These  simulated  target  rings  are  injected  digitally 
ahead  of  the  detection  signal  processor  (see  Figure  2-3). 

The  procedure  for  gauging  target  detectability  is  to  determine  the  minimum  dis¬ 
cernible  signal  (MDS)  ring  at  each  azimuth  cell;  this  roughly  indicates  the  minimum 
target  RCS  that  can  be  detected  at  the  ring’s  range.  Comparison  of  the  MDS  before 
and  after  AI  adaptivity  (with  constant  scan  time)  thus  provides  an  approximate  vi¬ 
sual  indication  of  the  advantage  in  dB  afforded  by  AI  as  function  of  azimuth  (and 
also  as  a  function  of  range  by  moving  the  range  position  of  the  rings). 

We  considered  two  options  for  injecting  the  simulated  target  rings:  the  existing  target 
simulator  (digital  injection)  or  the  HP8770  Arbitrary  Waveform  Synthesizer  (AWS) 
and  existing  up-converter  circuitry  to  inject  the  signal  at  the  C-Ba,nd  antenna.  Both 
implementations  are  straightforward.  The  former  technique  has  disadvantages  in  that 
no  more  than  two  target  rings  can  be  generated  by  the  existing  equipment  and  the 
injection  point  bypasses  the  sidelobe  blanker,  sidelobe  canceller,  and  environmen¬ 
tal  signal  processing.  The  latter  technique  requires  some  software  to  calculate  the 
waveform  code  for  two  superimposed  targets  at  the  positions  of  the  rings  and  control 
software  for  reprogramming  the  AWS  in  concert  with  waveform  changes.  The  former 
was  chosen  due  to  its  relative  simplicity. 

3.5.3  AI  Display 

The  Al-specific  display  requirements  are  1)  to  provide  variable  levels  of  information 
about  the  adaptive  control  status  for  diagnostics  during  rulebase  development  (diag¬ 
nostic  output),  and  2)  to  inform  the  user  of  detected  environmental  conditions  and 
resulting  radar  parameter  changes  during  operation  (runtime  output).  Information 
to  be  displayed  is  selected  through  default  parameters  at  system  startup  or  through 
the  User  Interface  during  operation. 

Diagnostic  output  for  use  during  system  development  can  be  sent  to  a  file.  It  includes 

1.  Bearn  Scan  Data. 

2.  The  radar  parameters  array,  which  is  the  output  of  Determine  Applicable 
ECCM. 

3.  Beam  Information,  a  data  structure  which  merges  Priority  Zone  and  Quality 
Option  information. 
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Runtime  output  during  system  operation  can  be  sent  to  the  screen  and/or  to  a  file. 
It  includes 

1.  Sources  of  interference  identified  for  each  beam,  including  associated  parame¬ 
ters. 

2.  The  quality  option  selected  for  the  next  scan 

3.  Radar  Control  F'arameters  as  sent  to  the  HP2H7.  This  output  can  only  be  sent 
to  a  file  due  to  the  quantity  of  information. 

4.  Summary  of  the  interference  identified,  controls  applied,  and  dwell  time  allo¬ 
cated  for  each  beam. 

Typical  output  for  interference  identification  would  appear  as  follows: 

A  nb  cw  si  jammer  was  found  in  beam  1,  frame  1 
Peak.JNR  *  1.3339e+03,  Jammer.Range  *  1,  t*nd 
Mainlobe_Duty_Factor  ■  1.000 


or 


Ground  clutter  was  found  in  beam  3,  frame  1 

Peak.CNR  “  5.1289e+03,  CNR.Maxrange  *  1.1714e+03,  and 
Maxrange  *  1.5750e+04 

Typical  output  indicating  the  plan  for  the  next  scan: 

AI  results  for  Frame  1 


Beam 

Dwell  Time 
per  Beam 

Interferences 

Found 

ECCMs  Changed 

1 

0.057 

nb_cw_ml_ j  ammer 

frequency  chamged 

2 

0.057 

nb_cw_ml_j ammer 

frequency  changed 

3 

0.057 

nb_cw_ml_ j  ammer 

frequency  changed 

The  AI  Display  is  menu-driven  and  completely  self-explanatory.  Sample  dialogues 
are  included  in  the  User  Manual  (UM). 
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4  Demonstration  and  Training 

4.1  Overview 

The  formal  Integrated  Multi-Domain  Radar  Demonstration  occurred  on  April  17  and 
18,  1991.  This  consisted  of  a  briefing,  followed  by  a  demonstiatiori  of  the  IMRD 
configuration,  and  training  in  its  operation. 

At  the  briefing,  we  reviewed  IMRD  capabilities  and  plans  for  demonstration.  It  was 
also  an  opportunity  to  discuss  contract  findings  and  suggestions  for  further  work. 

The  demo  followed  the  Test  Plan  and  Procedures  for  Integrated  Ajulti- domain  Radar 
Demonstration,  delivered  on  April  17,  1991.  This  document  describes  equipment  set¬ 
up  procedures,  the  demonstration  plan,  and  the  specific  test  cases  wTh  their  expected 
results. 

During  training,  RLSF  personnel  learned  to  set-up,  operate,  and  modify  the  IMRD 
experiment.  Training  material  included  the  User  Manual  for  Integrated  Multi-Domain 
Radar  (CDRL  A006),  and  Training  Notes  for  Integrated  Multi-Domain  Radar  (CDRL 
A004),  both  delivered  on  April  17,  i991. 

The  remainder  of  this  section  describes  the  test  objectives  and  specific  categories  of 
test  conducted. 


4.2  Test  Objectives  and  Categories 

Demonstration  and  training  focused  on  three  test  objectives: 

1.  Identify  and  counter  single  sources  of  interference  in  radar  data. 

2.  Identify  and  counter  multiple  sources  of  interference  in  radar  d^ta. 

3  Allocate  dwell  time  based  on  user-specified  Priority  Zones  and  scan  times. 

Targets  of  opportunity,  as  available,  and  simulated  targets  injected  into  the  display 
were  observed  during  tests.  Three  categories  corresponding  to  these  objectives  are 
described  in  the  remainder  of  this  section.  Table  12  lists  the  specific  tests  that  were 
conducted  and  Appendix  J.9.2  cx)ntains  their  complete  descriptions. 

Category'  1:  Identify  Single  Sources  of  Interference  and  Adapt  lladar  Parame¬ 
ters.  Single  sources  of  interference  were  identified  by  the  ID  Passive  Interference  and 
ID  Active  Interference  rulebeises.  The  first  phase  of  each  of  these  tests  was  conducted 
with  the  AI  adaptive  control  turned  off.  The  AI  Display  listed  interference  identifi¬ 
cations,  but  with  no  subsequent  radar  parameter  changes  were  made.  The  following 
types  of  interference  were  identified: 
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1.  Jammers  discriminated  by  narrowband  or  wideband,  CW  or  pulsed,  and  main- 
lobe  or  sidelobe. 

2.  Ground  clutter. 

3.  Weather  clutter. 

Ihe  next  phase  of  each  of  these  tests  was  conducted  with  the  AI  adaptive  control 
turned  on.  The  A I  Display  listed  detections  and  subsequent  radar  parameter  changes 
as  selected  by  Determine  Applicable  ECCM. 

The  following  control  changes  were  made; 


interference 

Radar  Control  Output 

1.  NB  CW  and  pulsed  jammer 

Frequency  change 

2.  Pulsed  widelobe  sidelobe  jammer 

Sidelobe  blanking 

3.  CW  wideband  sidelobe  jammer 

Sidelobe  cancelling* 

4.  Ground  clutter 

MTI 

5..  Weather  clutter 

MTI,  transmit  polarization 

*  Sidelobe  cancelling  w>is  selected  by  the  Adaptive  Controller  in  software  but  was  not  implemented 
in  hardware. 

Bearn  dwell  time  was  increased,  as  necessary,  to  increase  the  transmit  energy  per 
beam  for  achieving  the  probabilities  of  detection  assigned  to  the  different  quality 
option  plans. 

This  category  is  implemented  by  test  cases  1  through  3  as  well  as  by  the  first  steps 
in  tests  4,  6,  and  7  listed  in  Table  12.  Test  4  was  also  conducted  with  the  ECCM  fre¬ 
quency  change  disabled  to  demonstrate  that  the  A I  rulebase  selects  alternate  controls 
when  the  first  ciioice  is  not  available. 

Category  2:  Identify  Multiple  Sources  of  Interference  and  Adapt  Radar  Param¬ 
eters.  Multiple  sources  of  interference  were  identified  by  the  ID  Passive  Interference 
and  ID  Active  Interference  rulebases.  This  was  conducted  with  AI  on.  The  AI  display 
listed  interference  detections  and  subsequent  radar  parameter  changes  as  selected  by 
Determine  Applicable  ECCM  subproblem. 

The  following  combinations  of  interference  were  identified: 
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1.  NB  jammers  and  ground  clutter 

2.  Two  NB  CW  jammers 

3.  Two  WB  CW  jammers 

4.  NB  Jammers  and  ground  and  weather  clutter  (weather  permitting) 

This  category  is  implemented  by  test  cases  4  through  7,  listed  in  Table  12. 

Category  3:  Allocate  Dwell  Time  Subject  to  Priority  Zones  and  Quality  Op¬ 
tions.  We  demonstrated  the  impact  of  user-defined  Priority  Zones  on  scan  time 
allocation  as  well  as  software  facilities  for  changing  Radar  Control  Parameters.  This 
was  conducted  with  AI  on  and  interference  detections  were  listed  on  the  AI  Dis¬ 
play.  Subsequent  control  changes,  as  selected  by  the  Determine  Applicable  ECCM 
subproblem,  and  beam  dwell  times,  as  calculated  by  the  Allocate  Radar  Resources 
subproblem,  were  also  displayed.  The  user  had  the  option  to  make  changes  to  the 
Priority  Zones  and  scan  time  and  to  observe  the  impact  on  resulting  dwell  time  and 
target  detectability  in  the  presence  of  various  types  of  interference. 

This  category  is  implemented  by  test  case  8,  listed  in  Table  12.  See  Figure  3-6  for 
the  Priority  Zones  and  types  of  interference  used  for  this  test. 
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Test 

Description 

Declaration 

Adaptive  Control 

0 

Benign  Environment 

1 

Ground  Clutter 

ground 

mti_weight  changed 

(poss.  Weather) 

weather 

tx-polarization  changed 
mti-weight  changed 

2 

WB  ASP  Jammer 

wb_asp_sLjammer 

sidelobe.blanking  or’ 

(or  -ml-jammer) 

D 

WB  CW  Jammer 

wb_cw_sLjammer 

sidelobe-cancelling  on 

H 

(or  _ml-jammer) 

B 

NB  CW  Jammer 

nb_cw_sLjammer 

frequency  changed 

(or  _ml_jammer) 

frequency  changed 

(plus  Ground) 

ground 

mti-weight  changed 

5 

Two  NB  CW  Jammers 

nb_c  w_sl_j  ammer 

frequency  changed 

(or_ml_jammer) 

frequency  changed 

(plus  Ground) 

ground 

mti-weight  changed 

6 

NB  ASP  Jammer 

nb_asp_sLj  ammer 

(or  -mLjammer) 

frequency  changed 

(plus  Ground) 

ground 

mti-weight  changed 

■ 

NB  ASP,  no  freq.  change 

nb_aspjELjaminer 

nb_asp_ml-Jammer 

sidelobe_blanking  on 

■ 

(plus  Ground) 

ground 

mti_weight  changed 

B 

Quality  Options 

wb_cw 

dwell  time  adjustments 

Table  12:  IMRD  Test  Cases 
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5  Conclusions  and  Recommendations 

The  IMRD  program  has  successfully  demonstrated  the  feasibility  of  an  Al-based 
adaptive  radar  controller  implemented  on  a  real,  as  opposed  to  a  hypothetical,  radar 
system.  In  doing  so,  a  major  step  has  been  taken  toward  the  longer-term  goal  of  em¬ 
ploying  knowledge- based  radar  control  on  operational  advanced  tactical  surveillance 
radar  syvstems.  We  believe  that  this  program  has  established  a  solid  foundation  for 
capability  enhancements  and  additional  investigations  using  the  testbed  equipment. 

5.1  Major  Conclusions  and  Lessons  Learned 

Our  program  achievements  include: 

1.  Successful  demonstration  of  all  components  of  the  knowledge-based  controller 
in  a  real-world  scenario,  including  the  ability  to  assess  and  discriminate  among 
multiple  interference  sources,  to  formulate  candidate  plans  of  action  to  improve 
target  detectability,  to  choose  the  plan  that  best  meets  user-defined  scan  time 
and  priority  zone  constraints,  and  to  carry  out  the  plan  via  changing  control 
parameters  for  a  real  radar  system. 

2.  Extensive  signal  and  data  processing  capabiUties  implementation  in  real-time 
using  available  RLSF  equipment. 

3.  A  testbed  and  performance  benchmark  to  enable  the  government  continued 
rulebase  evolution;  we  have  trained  RLSF  personnel  to  use  it. 

4.  Hardware  and  software  documentation  to  facilitate  development. 

Accomplishing  the  above  was  a  challenge  due  to  the  leading-edge,  exploratory  nature 
of  the  effort,  and  to  our  decision  to  use  the  RLSF  equipment  at  near  maximum 
capabilities.  As  a  result,  many  issues  were  flushed  out  that  would  not  have  emerged 
from  a  paper  study.  We  therefore  consider  this  report’s  documentation  of  lessons 
learned  and  of  the  design  evolution  to  be  as  important  &s  the  successful  demonstration 
performed  at  the  conclusion  of  the  contract. 

Lessons  learned  are  discussed  throughout  this  report.  Some  of  the  more  substantial 
observations  are  surrunarized  below. 

Rulebase  Development:  Of  all  challenges  we  faced  during  this  contract,  the  most 
difficult  and  time-consuming  was  defining  a  robust  AI  rulebase  for  identifying  interfer¬ 
ence,  especially  when  the  observed  data  contains  multiple,  overlapping  interference 
sources.  It  was  difficult  to  develop  a  set  of  rules  that  matches  the  effectiveness  of 
an  experienced  human  operator  in  recognizing  and  discriminating  interference.  This 
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problem  was  exacerbated  by  real-world  factors  such  as  equipment  errors  and  variabil¬ 
ity  in  the  appearance  of  the  interference.  For  example,  the  range  and  doppler  charac¬ 
teristics  of  weather  are  dependent  on  many  factors  including  rainfall  rate,  beam  angle 
with  respect  to  the  wind,  wind  velocity,  and  location  of  the  rain. 

Real-Time  Operation:  The  second  most  difficult  challenge  was  paring  down  system 
functionality  to  enable  real-time  operation  within  equipment  and  contract  resources. 
Indeed,  we  evaluated  a  number  of  more  sophisticated  control  features,  processing 
techniques,  and  rulebase  capabilities  that  may  be  applicable  to  an  eventual  opera¬ 
tional  radar,  but  these  were  not  implemented  because  the  performance  improvements 
(i.e.,  credibility  enhancements  for  the  demonstration)  were  insignificant  compared 
with  the  additional  program  risk.  Our  philosophy  was  that  the  successful  demon¬ 
stration  of  modest  capabilities  was  preferable  to  an  unsuccessful  demonstration  of  a 
more  elaborate  system.  The  result  of  this  philosophy  is  a  firm  foundation  on  which 
additional  capability  can  be  built. 

Provisions  for  Growth;  While  focussing  on  achieving  a.  working  demonstration,  we 
needed  to  build  in  flexibility  for  eventual  system  enhancement  and  evolution.  We  have 
accomplished  this  through  overall  design,  software  modularity,  and  parameterization. 
As  a  result,  this  testbed  is  a  foundation  for  rulebase  evolution  within  RLSF  C-Band 
radar  and  can  be  configured  for  or  evolve  to  different  equipment  environments. 

AI  versus  Human  Intelligence:  The  bottom-line  is  Inevitably  how  does  a  human 
operator  compare  to  the  AI  controller.  One  may  argue  that  an  experienced  human 
will  be  at  least  as  effective  as  the  AI  controller  in  recognizing  interference  and  making 
simple  changes  to  radar  control  such  as  turning  on  a  sidelobe  blanker  or  changing 
the  radar  frequency.  However,  two  major  advantages  of  the  A I  controller  over  a 
human  operator  are  its  automation  relative  to  a  human  operator  (with  capability  for 
unattended  radar  operation)  and  its  ability  to  make  complicated  real-time  control 
decisions  that  may  be  beyond  human  capability.  Examples  of  such  decision  policies 
are  the  Priority  Zone  and  Quality  Option  plans  demonstrated  under  this  contract. 

5.2  Suggestions  for  Future  Work 

5.2.1  Rulebase  Development 

The  following  sections  suggest  improvements  that  might  be  made  in  identifying  the 
different  sources  of  interference. 


5. 2. 1.1  Neural  Net  Implementation 
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Because  of  their  ability  to  find  patterns  in  noisy  data,  neural  nets  are  applicable  to 
interference  identification.  The  expert  system  submodules  which  identify  jammers 
and  clutter  could  be  replaced  by  neural  nets  whose  input  neurons  correspond  to 
elements  in  the  Bearn  Scan  Data  and  whose  outputs  are  interference  identifications. 
Taped  radar  data  from  the  RLSF  C-Band  radar  would  be  used  to  train  the  neural 
net  and  to  compare  neural  net  and  expert  system  performance. 

The  major  outcomes  of  this  would  be  enhanced  performance  of  the  AJ  testbed  and 
an  opportunity  for  technology  assessment  through  the  neural  net /expert  system  com- 
parision. 

IMRD  Enhancement:  The  IMRD  rules  for  identifying  interference  are  relatively 
straightforward  and  are  based  on  the  reasoning  of  radar  experts.  Neural  net  super¬ 
vised  learning  should  allow  the  system  to  reflect  the  real  environment  more  accurately, 
and  to  better  accommodate  noise  data.  .4s  the  system  evolves,  changing  environments 
can  be  modeled  by  adjusting  neuron  weights  through  new  training  cases  more  effi¬ 
ciently  than  if  expert  system  rules  needed  to  be  redefined. 

Neural  Net  Technology  Assessment:  Comparative  performance  measurement  is 
one  component  of  the  DARPA  program  In  Artificial  Neural  Networks.  Its  objective 
is  to  determine  the  advantages  and  disadvantages  of  neural  nets  with  respect  to 
conventional  technologies.  Looking  for  interference  patterns  in  noisy  data  appears  to 
be  a  natural  application  for  neural  nets,  and  IMRD  presents  a  convenient  opportunity 
to  make  such  a  comparison  with  expert  system  technology. 

5. 2. 1.2  Uncertain  Knowledge 

A  nrieasure  of  certainty  could  be  included  in  eacii  interference  identification  to  use  in 
the  plan  selection  for  the  next  scan.  Uncertainty  was  to  some  extent  incorporated 
into  JNR  and  CNR  measurements  that  accompanied  detections,  but  no  explicit  prob¬ 
abilities  were  used.  This  higher  level  of  sophistication  would  have  been  overkill  at 
this  stage  will  be  appropriate  as  the  rulebase  evolves.  Among  possible  models  are 
Bayesian  probability,  certainty  factors,  Dempster-ShafTer  logic,  and  fuzzy  sets.  These 
should  be  reviewed  in  the  context  of  contract  achievements. 

Bayesian  probability  is  most  applicable  when  conditional  probabilities  among  events 
ait  understood.  For  example,  it  would  be  useful  to  correlate  detections  over  multiple 
scajis  or  in  adjacent  beams. 

Cc!rtainty  factors  are  a  popular  way  to  build  uncertainty  in  a  rulebase,  but  fairly  ad 
hoc  and  hard  to  validate.  Implementing  them  in  the  current  Prolog  rules  would  be 
straightforward. 

Demster  Shaffer  logic  entails  a  set  of  beliefs  about  the  truth  of  an  event.  It  is  more 
qualitative  than  this  application,  but  could  be  appropriate  in  a  system  that  supports  a 
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greater  level  of  real-time  tactical  input  by  the  operator.  There  is  some  disagreement 
about  the  best  way  to  incorporate  this  logic  into  inferencing,  but  several  different 
options  could  be  explored. 

Fuzzy  sets  are  particularly  good  mode!  for  areas  such  as  sensor  fusion  where  in¬ 
formation  from  independent  sources  is  available.  They  could  be  applied  to  merging 
independent  determinations  of  interferences  such  as  from  separate  rulebases  on  phys¬ 
ically  separated  systems. 


5. 2. 1.3  Jammers 

Wideband  jammer  identification  could  be  improved  by  maintaining  a  scan-to-scan 
history  of  jammer  mecisurernents,  with  each  measurement  at  a  different  frequency, 
or  preferably  by  a  wide-open  instantaneous  bandwidth  receiver  that  covers  the  en¬ 
tire  radar  agile  bandwidth.  The  former  would  require  an  increase  in  data  processing 
software  complexity,  the  latter,  additional  equipment  with  very  high-speed  A/D  con 
verters. 

For  a  low-power  pulsed  jammer  with  low  duty  factor  (i.e.,  very  low  average  power 
jamming  signals),  improvements  in  sensitivity  and  accuracy  of  the  jammer  bandwidth 
measurement  could  be  afforded  by  confining  the  spectral  analysis  (i.e.,  F'FT)  to  those 
samples  within  the  detected  jammer  pulse  rather  than  over  the  entire  PRI  interval. 

Improvements  of  the  adaptive  control  response  for  narrowband  jammers  could  be  af¬ 
forded  by  choosing  the  least-jammed  frequency  based  on  a  scan-to-scan  history  or 
possibly  a  pseudorandom  selection.  Presently,  frequency  changes  are  made  sequen¬ 
tially  over  the  channel  spacing  of  the  C-Band  radar. 

5. 2. 1.4  Ground  Clutter 

A  constant  clutter  detection  threshold  was  implemented  for  all  range  and  doppler. 
This  threshold  must  be  set  low  enough  so  that  returns  near  the  maximum  clutter  range 
are  detected.  However,  low  threshold  settings  cause  false  detections  in  the  doppler 
sidelobes  of  near-range  ground  clutter.  A  suggested  improvement  is  a  range  varying 
threshold,  or  preferably  STC  preprocessing  to  better  model  the  approximately  1/R^ 
level  variation  of  the  ground  return. 

To  estimate  clutter  power  versus  range  and  doppler,  the  range-doppler  plane  was 
segmented  into  block  integrations  for  smoothing  the  variations.  Additional  smoothing 
and  suppression  of  moving  targets  and  nonstationary  interference  could  be  afforded 
by  calculating  a  scan-to  scan  clutter  map. 

Ground  clutter  assessments  are  made  at  every  beam  position  for  every  scan  to  satisfy 
the  SOW  requirement  of  a  one-scan  reaction  time  to  changes  in  the  environment. 
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This  one  scan  response  is  perhaps  overkill  in  a  groundbased  radar  since  ground  con¬ 
ditions  will  not  change  rapidly.  Therefore,  to  free  up  the  radar  timeline  and  reduce 
processing,  it  makes  sense  to  perform  these  measurements  less  frequently.  This  can 
be  accomplished  by  using  the  software  capability  to  change  CPI2  update  rate  that  is 
built  into  the  Quality  Options  Tables. 


5. 2. 1.5  Weather  Clutter 

The  weather  ID  function  is  performed  on  every  beam  and  every  scan  using  the  CPI'i 
waveform.  Identifications  are  based  on  integrating  the  clutter  power  in  the  wedgelike 
range-doppler  region  where  the  clutter  is  expected  to  appear,  as  well  on  as  counting 
lange-doppler  cell  threshold  crossings  in  that  region.  Even  though  we  successfully 
identified  weather  interference  based  on  range-doppler  characteristics,  the  rulebase 
could  be  made  more  robust  by  using  additional  discriminants  or  by  more  complex 
estimation  of  interference  statistics. 

As  with  the  ground  clutter  declaration,  a  range- varying  threshold  (on  the  order  of 
1/R^)  should  improve  the  sensitivity  and  accuracy  as  well  as  multiple  scan  integration 
for  additional  smoothing.  To  save  radar  timeline  and  reduce  the  processing  load,  the 
weather  may  not  need  to  be  measured  on  every  scan  since  it  will  not  change  rapidly. 

Additional  measurement  discriminants  would  also  offer  improvement.  Two  examples 
are  incorporating  the  power  ratio  of  same-sense  versus  opposite  sense  circular  polar¬ 
ization,  and  including  the  variability  ratio  discriminant  that  is  already  calculated  by 
the  ST- 100  but  not  used  in  the  rulebase.  The  former  technique  was  not  implemented 
since  we  believed  that  the  equipment  interface  modifications  required  to  do  so  would 
have  exceeded  contract  resources. 


5. 2. 1.6  Overlapping  Interference 

Suggestions  to  alleviate  problems  with  overlapping  interference  include: 

1.  Incorporate  jammer  cancellation  during  CPI2  (via  SLB,  SLC,  and  MLC)  to 
improve  isolation  of  measurements  by  reducing  or  eliminating  jamming  signals 
that  tend  to  interfere  with  the  ID  clutter  process. 

2.  Incorporate  additional  discriminants  such  as  variability  ratio,  polarization  ratio, 
or  determination  of  clusters. 

3.  Use  range-varying  thresholds  to  improve  sensitivity  of  clutter  detection. 


5. 2. 1.7  Multiple  Scan  Processing 
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In  addition  to  the  single  scan  growth  items  discussed  previously,  track-while-scan 
processing  of  multiple  targets,  of  point  clutter  sources,  and  of  jammer  sources  could 
be  considered  for  a  follow-on  effort.  Rulebase  enhancements  could  be  formulated  to 
examine  track  features  and  insure  radar  survivability.  A  multi-scan  history  of  past 
ECCM  could  be  maintained  so  that  the  AI  rulebase  can  deal  with  paist  failures,  or 
maintain  past  success  in  optimizing  the  radar  response  to  the  target,  clutter,  and 
jamming  environment. 

Additional  mecisures  that  could  be  made  include 

1.  Passive  dwell  measures  (for  each  jammer):  angle,  angle  rates  and  polarization, 
polarization  rate,  %  jamming  duty  versus  time,  inband  frequency  modulation, 
and  mean  and  variance  of  amplitude  versus  time  and  doppler. 

2.  Active  dwell  point  clutter  measures:  radar-based  position  and  velocity  state 
versus  time  of  point  clutter,  erratic  motion  targets,  and  track  quality  indicators 
(missed  reports,  SNR) 

3.  Active  dwell  target  measures  (for  each  target):  principle  and  opposite  polar¬ 
ization  amplitude  statistics  versus  time,  inertial  position  and  velocity  state  of 
credible  targets  versus  time,  inertial  position  and  velocity  cxwariance  of  credi¬ 
ble  targets  versus  time,  and  track  quality  indicators  (missed  reports,  residuals, 
SNR). 

Potential  additional  control  responses  not  implemented  in  the  present  AI  testbed 
which  could  be  simulated  or  executed  in  the  real  test  environment  are  summarized  in 
Table  13. 

Table  14  summarizes  potential  scan  to  scan  environmental  measures.  A  brief  discus¬ 
sion  for  two  of  them  follows. 

Point  Clutter  Map  (PCM):  A  PCM  could  be  implemented  as  an  m-scan  history 
track-while-scan  (TWS)  file  maintained  in  radar  coordinates.  The  PCM  inhibits 
reporting  point  clutter  or  target  returns  which  do  not  satisfy  operator-designated 
threat  characteristics  in  terms  of  speed,  heading,  and  maneuverability.  The  PCM 
also  inhibits  reporting  point  clutter  returns  which  do  not  associate  from  scan  to 
scan.  This  allows  identification  of  interference  as  uncorrelated  clutter  due,  perhaps,  to 
anomalous  propagation,  or  to  correlated  returns  such  as  bird  flocks.  Such  information 
is  important  in  subsequent  scan  waveform  selection.  As  part  of  an  adaptive  control, 
the  target  screening  characteristics  may  be  changed,  according  to  operator  designated 
priority,  to  increase  or  decrease  the  point  clutter  screening  performed  by  the  PCM. 

Target  Track-While-Scan  File:  The  target  TWS  file  could  be  implemented  as  a 
multi-scan  history  of  track  states  established  on  credible  targets  which  survive  the 
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Applicable  ECCM 

Rationale 

Intradwell  frequency  agility 

Estimate  target  parameters 

Bandwidth  increase 

Resolve  targets  versus  point  clutter 

Beampacking  adjustment 

Increase  target  detectability 

Beamspoiling  adjustment 

Increase  azimuth  coverage 

Adaptive  AGC/STC 

Respond  to  saturating  targets/clutter 

Adaptive  track  filter  gain, 

Detect  and  respond  to  target  maneuvers 

correlation  gates,  update 
rates 

and  jammer  angle  maneuvers 

Adaptive  point  clutter,  filter 

Maintain  false  alarm  control  on  point  clut- 

gain,  gates,  update  rates 

ter,  erratic  motion  targets 

Designation  to  alternate 
RLSF  radar  (S-  or  L-Band) 

Avoid  spot  or  barrage  jamming 

Emission  control  (EMCON) 

Survival  during  antiradiation  missile 
(ARM)  launch  event 

Decoy  activation 

Survival  during  ARM  launch  event 

Table  13:  Additional  Active  Target  Measures  and  ECCM 


Interference  Estimate 

Purpose 

Point  clutter  map 

Birds,  discrete  clutter,  anomolous 

propagation 

Passive  dwell  jammer  map 

Non-responsive  jammers 

Active  dwell  jammer  map 

Responsive  jammers 

Active  dwell  clutter  map 

Area  and  volume  scatters 

Target  TWS  file 

Credible  targets 

Table  14:  Potential  Scan-to-Scan  Environment  Sensors 
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PCM  discriminants.  Track  states  are  maintained  in  an  inertial  coordinate  set  (such  as 
local  topocentric)  to  allow  maximum  observability  of  target  motion  components,  ease 
of  track  maintenance  and  propagation,  and  fusion  with  other  sensor  data.  Although 
the  track  states  could  be  updated  primarily  by  successive  surveillance  scans  of  the 
C-Band  radar,  track  states  from  the  S-Band  dish  tracker  could  also  be  considered. 
The  target  TWS  file  would  provide  the  AI  decision-making  process  with  an  accurate, 
unambiguous  history  of  target  motion,  particularly  acceleration  and  split  track  events 
(i.e.,  missile  launch)  and  allow  assessment  of  threatening  events.  Similarly,  the  jam¬ 
mer  TWS  file  would  provide  an  accurate,  unambiguous  history  of  jammer  angular 
motion.  Tracking  software  would  most  likely  be  hosted  on  the  VAX. 

A  digital  report  extractor  would  be  required  in  the  PTF  signal  processor  string  to 
provide  target  digital  range,  angle,  SNR  reports  to  the  TWS  host  computer.  The 
Sensis  MSC  68000  platform  is  a  potentially  cost-effective  implementation  technique. 
As  a  less  costly  alternative,  the  digital  buffer  which  is  presently  at  the  output  of  the 
PTF  string  may  be  sufficient.  This  lOK  buffer  records  limited  data,  however,  and 
requires  significant  overhead  time  to  read  the  data  into  the  HP2117  and  VAX.  The 
VAX  must  then  extract  digital  range  and  angle  reports. 


5.2.2  DC  Offset 

Small  amounts  of  DC  offset  in  the  receive  video  amplifiers  or  A/D  converters  lie  in  the 
zero  doppler  bin  and  can  mask  ground  and  weather  returns  in  the  doppler  mainlobe 
and  sidelobes,  respectively.  The  DC  offset  was  manually  adjusted  to  below  an  LSB 
prior  to  each  demo  of  the  AI  testbed,  but  it  tended  to  drift  with  time  and  varied  by 
about  an  LSB  depending  on  whether  the  transmitter  was  on  or  off  (perhaps  this  was 
due  to  slight  chamges  in  ground  voltage  potential). 

One  solution  is  to  build  a  software  DC  canceller  in  the  ST-100  with  the  requisite  time 
constant.  In  moderate  wind,  ground  clutter  has  a  velocity  standard  deviation  of  about 
.1  m/sec,  or  3.33  Hz  at  C-Band.  To  remove  the  DC  offset  without  cancelling  significant 
portions  of  the  ground  clutter  requires  a  canceller  bandwidth  that  is  substantially  less; 
a  time  constant  of  greater  than  three  seconds  would  be  sufficient. 

5.2.3  Signal  Processing 

The  signal  processing  in  the  current  IMRD  configuration  is  limited  by  the  capabilities 
of  the  real-time  signal  processing  hardware  and  by  the  throughput  and  I/O  capac¬ 
ity  of  the  ST-100.  Additional  signal  processing  hardware  would  allow  for  system 
enhancement  such  2is  target  detection  processing,  simultaneous  transmission  and  pro¬ 
cessing  of  the  active  environmental  assessment  dwell  (CPI2)  and  the  detection  dwell 
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(CPI3),  and  finer  granularity  of  the  range  and  frequency  vectors  to  allow  more  precise 
characterization  of  the  environment. 

The  current  system  and  ruleba.se  estimate  signal-to-noise  improvements  based  on 
assumed  ECCM  effectiveness  against  a  postulated  target.  There  is  no  feedback  in  the 
rulebase  to  evaluate  the  effectiveness  of  the  system  to  improve  target  detectability 
and  reduce  false  alarms.  With  increased  signal  processing  capability,  quantifiable 
performance  improvement  could  be  made  using  target  data  (both  simulated  and  real) 
obtained  during  CPI3. 

Parallel  channels  into  the  signal  processor  would  provide  the  capability  to  process 
two  or  more  of  the  transmitted  waveforms  simultaneously.  For  example,  if  the  raw 
radar  from  a  single  active  dwell  were  available  to  the  signal  processor,  it  could  derive 
both  the  environmental  assessment  data  and  the  detection  data  from  the  raw  input. 
The  main  advantage  to  this  enhancement  is  a  reduction  in  total  scan  time. 

Additional  signal  processing  horsepower  would  allow  for  larger  numbers  of  range  and 
frequency  samples  to  be  evaluated  during  environmental  assessment.  In  the  current 
system,  several  radar  range  cells  are  averaged  to  form  a  composite  processing  range 
cell  due  to  the  limited  processing  throughput  of  the  ST-100  and  scan  time  require¬ 
ments.  Finer  range  resolution  of  targets  and  clutter  would  be  gained  by  utilizing 
smaller  range  cells.  Larger  FFT  sizes  could  also  be  used  to  give  better  estimates  of 
the  passive  interference  frequency  characteristics. 


5.2.4  Radar  Control 

Initially,  we  intended  to  implement  the  Radar  Controller  exclusively  by  the  HP2117 
software,  augmented  with  the  existing  RTCU  and  remote  module  capabilities.  During 
the  implementation  and  test  phase  of  the  contract,  however,  the  design  evolved  toward 
a  hardware  controller.  For  example,  the  3-CPI  circuit  performs  one  of  the  functions 
originally  intended  for  the  HP2117.  In  retrospect,  a  special-purpose  hardware  con¬ 
troller  implementation  might  have  been  more  suitable  for  the  remaining  functions, 
although  success  was  still  achieved  using  the  HP2117  for  this  function. 

This  evolution  should  be  continued  in  the  context  of  projected  RLSF  radar  control 
needs.  The  alternate  Adaptive  Controller  platform  (Section  5.2.6)  could  provide  an 
interface  to  this  control  function. 

5.2.5  Enhanced  Graphics  Display 

The  present  system  has  a  somewhat  limited  display  capability  since  the  detection 
waveform  is  displayed  on  a  PPL  A  graphics  display  would  allow  the  AI  information 
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now  displayed  on  a  separate  terminal  to  be  merged  with  the  detection  information 
into  a  single,  integrated  display.  Additional  CPIS  processing  would  be  necessary  to 
format  the  data  for  an  enhanced  graphics  display  showing  the  areas  of  interference 
(jamming  and  clutter)  as  well  as  target  returns. 

5.2.6  Alternate  Adaptive  Controller  Host 

The  VAX  has  allowed  a  real-time  demonstration  of  adaptive  control  and  has  been  a 
convenient  development  vehicle.  However,  it  is  not  specifically  appropriate  for  real¬ 
time  processing  and  the  current  AI  testbed  is  operating  at  the  edge  of  its  processing 
capabilities.  Other  platforms  (e.g.,  one  or  several  Suns)  would  allow  more  flexibility 
for  an  expanded  rulebase,  additional  signal  processing  as  suggested  in  Section  5.2.3, 
for  other  hardware  interfaces  for  radar  control  (Section  5.2.4),  and  for  the  graphics 
display  Section  5.2.5).  Including  higher  speed  processors  to  perform  the  interscan 
computations  such  cis  allocating  radar  resources  (currently  approximately  2-3  seconds 
per  scan)  would  also  decrease  the  scan  rate.  The  portability  of  the  Prolog  code,  as 
discussed  in  Section  3. 3. 3.1,  would  support  this  evolution. 


6  Acronyms  and  Abbreviations 


Acronym 

Definition 

ACMDSP 

Adaptive  Control  for  Multi- Domain  Signal  Processing 

AI 

Artificial  intelligence 

ASP 

Asynchronous  pulsed 

CFAR 

Continuous  false  alarm  rate 

CNR 

Clutter-to-noise  ratio 

CPI 

Coherent  processing  interval 

CPU 

Central  processing  unit 

CW 

Continuous  wave 

DARPA 

Defense  Advanced  Research  Projects  Agency 

dB 

Decibels 

DC 

Direct  current 

DCU 

Digital  control  unit 

DHI 

Digital  hardware  interface 

DSP 

Detection  signal  processing 

ECCM 

Electronic  counter-counter  measure 

EMCON 

Emission  control 

ESP 

Environmental  signal  processing 

EFT 

Fast  Fourier  transform 

FRDE 

Flexible  Radair  Data  Executive 

GAFB 

Griffiss  Air  Force  Base 

GFE 

Government  furnished  equipment 

IF 

Intermediate  frequency 

IMRD 

Integrated  Multi- Domain  Radar  Demonstration 

JNR 

Jammer-to-noise  ratio 

LFM 

Linear  frequency  modulation 

LSB 

Least  significant  bit 

MLC 

Mainlobe  canceller 

M3LC 

Multiple  sidelobe  canceller 

MTI 

Moving  target  indicator 

Acronyms  and  Abbreviations 
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Acronym 

Pftfinition 

NB 

Narrowband 

PC 

Pulse  compressor 

PCM 

Point  clulter  map 

Pd 

Probability  of  detection 

PPI 

Plan  position  indicator 

PRI 

Pulse  repetition  interval 

PSTG 

Phase  shifter  timing  gate 

PTF 

Prograttmable  transversal  filter 

RCS 

Radar  cross  section 

RF 

Radio  frequency 

RFI 

Radio  frequency  interference 

RLSF 

Rome  Laboratory  Surveillance  Facility 

RTCU 

Radar  timing  and  control  unit 

SIR 

Signal-to-interference  ratio 

SLB 

Sidelobe  blanker 

SLC 

Sidelobe  canceller 

SNR 

Signal-to-noise  ratio 

SOW 

Statement  of  work 

SPI 

ST-100  to  PPI  Interface 

STC 

Sensitivity  time  control 

TWS 

Track  while  scan 

WB 

Wideband 

WFG 

Waveform  generator 
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A  Radar  Design  Parameters 

Radar  Design  Parameters  define  the  radar  that  is  being  adaptively  controlled.  They 
are  read  from  three  files  at  system  initialization  into  a  Pascal  variable  of  de- 
sign_data_type.  The  files  are  stored  in  ASCII  format.  Note  that  all  values  read  in  as 
dB  are  converted  internally  to  ratio  values  prior  to  insertion  in  the  design_data_type 
record. 


A.l  Data  Description 

Radar  Design  Parameters  contain  the  following  components; 

Number-Faces  is  an  integer  between  1  and  4  representing  the  number  of  active  faces 
in  the  radar.  This  is  set  to  1  in  the  IMRD  but  the  software  will  have  the  flexibility 
to  model  a  radar  with  up  to  4  faces. 

Number_El_Angles  is  an  integer  between  1  and  40  representing  the  number  of  ele¬ 
vation  angles  in  a  scan.  This  is  set  to  1  in  the  IMRD  but  the  software  will  have  the 
flexibility  to  model  a  radar  with  up  to  40  elevation  angles. 

Azimuth-Limits  contains  the  following  real  data  for  each  radar  face: 

•  Start_Az  is  the  first  angle  of  the  array  face  to  be  scanned. 

•  End-Az  is  the  last  angle  of  the  array  face  to  be  scanned. 

Set  to  -22.5  degrees,  -}"22.5  degrees  respectively  in  the  IMRD  (angle  is  referenced  to 
array  normal.) 

Maoc-Range-Cells  is  an  integer  between  1  and  32  representing  the  maximum  number 
of  integrated  range  cells  for  active  and  passive  rang’  measurements.  In  the  IMRD  the 
width  of  these  range  cells  (  set  to  4.5  km)  is  30  times  the  width  of  the  A/D  output 
range  cells  due  to  integration.  Set  to  30  in  the  IMRD. 

Max-Doppler-Cells  is  an  integer  between  1  and  16  representing  the  maximum  num¬ 
ber  of  doppler  cells  for  active  doppler  measurements.  Set  to  16  in  the  IMRD.  Note 
that  this  variable  applies  only  to  the  active  dwell  (CPI2)  doppler  measurement. 

MaxJPassJDop-Cells  is  an  integer  between  1  and  32  representing  the  maximum 
number  of  integrated  frequency  cells  for  passive  frequency  measurements.  In  the 
IMRD  the  width  of  these  frequency  bins  (nominally  31.25  KHz)  is  1/32  of  the  A/D 
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sampling  rate  due  to  integration  of  the  raw  data  FFT  output.  Set  to  32  in  the  IMRD. 
Note  that  this  variable  applies  only  to  the  passive  dwell  (CPU)  doppler  measurement. 

Pe.ak_Power  is  a  real  number  between  50,000  and  250,000  W  representing  the  peak 
power  output  of  the  transmitter.  Set  to  100,000  W  in  IMRD. 

Boresight-Gain-dB  is  a  real  number  between  0  and  35  dBI  representing  the  maxi¬ 
mum  antenna  gain  at  the  beam  peak.  Set  to  31  dBI  in  IMRD. 

Number_Of_D wells  is  an  integer  between  1  and  100  representing  the  number  of  beam 
positions  per  scan.  Set  to  40  in  the  IMRD. 

Coher-Bursts-PerJBeam-Dwell  is  an  integer  between  1  and  16  representing  the 
number  of  coherent  bursts  in  each  beam  dwell  transmitted  during  CP13.  This  is  not 
used  in  the  IMRD. 

Samples_per_PRI  is  an  integer  between  900  and  1100  representing  the  number  of 
data  samples  per  PRI  processed  by  the  ST- 100  for  each  assessment  dwell.  Set  to  900 
in  the  IMRD. 

Number_of_PRI  is  an  integer  between  4  and  64  representing  the  number  of  PRIs  in 
the  active  and  passive  listening  dwells.  Set  to  16  in  the  IMRD. 

PRI  is  a  real  number  between  le-6  and  4096e-6  representing  the  pulse  repetition 
interval  of  the  current  beam  in  seconds.  Set  to  3000e-6  in  the  IMRD. 

Sigma-Q  is  a  read  number  representing  the  ratio  of  thermal  noise  rms  to  the  A/D 
quantization  level.  Set  to  1.0  in  the  IMRD. 

Max_Radar.PreqJndex  is  an  integer  between  1  and  16  representing  the  number  of 
unique  radar  frequency  settings.  Set  to  8  in  the  IMRD. 

Nominal-RadarJPreq  is  a  real  number  representing  the  center  frequency  in  Hz  at 
which  the  radar  is  transmitting.  Set  to  5.775e9  Hz  in  the  IMRD. 

Radar-Instantaneous-BW  is  a  real  number  between  0  and  10e6  Hz  representing  the 
instantaneous  waveform  bandwidth.  Set  to  le6  Hz  in  the  IMRD. 

ECCM-Available  is  a  record  variable  representing  the  ECCM  that  arc  enabled  within 
the  radar.  Each  boolean  record  indicates  whether  that  ECCM  is  enabled  or  disabled. 

•  SL_Blanking_On  represents  whether  the  sidelobe  blanker  is  available. 
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•  SL-Cancelling_On  represents  whether  the  sidelobe  canceller  is  available. 

•  Freq_Change  represents  whether  the  transmit  frequency  can  be  changed. 

•  Circular_Polar  represents  whether  receive  polarization  can  be  changed. 

Sig_To-Jam_Improve  is  a  real  number  between  0  and  30  dB  representing  the  im¬ 
provement  in  signal  to  noise  ratio  achieved  by  employing  sidelobe  cancellation.  Set 
to  0  dB  in  the  IMRD. 

Polar-Rain-Gain  is  a  real  number  between  0  and  20  dB  representing  the  increase  in 
SCR  achieved  by  applying  polarization  techniques  to  improve  radar  detection  in  rain 
clutter.  Set  to  10  dB  in  the  IMRD. 

Polar-Target -Loss  is  a  real  number  between  0  and  10  dB  representing  the  loss  in 
SNR  caused  by  employing  polarization.  Set  to  7  dB  in  the  IMRD. 

M'W-Loss-Trans-To-Antenna  is  a  real  number  between  0  and  5  dB  representing  the 
loss  in  the  signal  path  from  the  transmitter  to  the  antenna.  Set  to  1.5  dB  in  the 
IMRD. 

MWJLoss_Antenna_To_Preamp  is  a  real  number  between  0  and  5  dB  representing 
the  loss  in  signal  path  from  antenna  to  the  preamp.  Set  to  1.5  dB  in  the  IMRD. 

Signal-Processing-Loss  is  a  real  number  between  0  and  10  dB  representing  the  loss 
suffered  by  a  signal  due  to  signal  process-ng  techniques  employed.  Set  to  5  dB  in  the 
IMRD. 

Freq-SidelobeJLevel  is  a  real  number  between  0  and  100  dB  representing  the  JNR 
improvement  achieved  by  employing  frequency  hopping.  Set  to  lOeS  in  the  IMRD. 

Antenna-Sidelobe  is  a  real  number  between  0  and  50  dB  representing  the  antenna 
sidelobe  level  in  dB.  Set  to  25  dB  in  the  IMRD. 

Sampling-Rate  is  a  real  number  between  500e3  and  10e6  Hz  specifying  the  sample 
rate  of  the  video  A/D  converters.  Set  to  le6  Hz  in  the  IMRD. 

Nom-Target-RCS  is  a  real  number  between  -30  and  -f30  dBsm  representing  the 
required  minimum  cross  section  of  a  target  to  be  detected.  Set  to  10  dBsm  for 
IMRD. 

No m_Target -Range  is  a  real  number  between  0  and  200e3  meters  representing  the 
desired  detection  range  to  the  target.  Set  to  40.t>s3  m  in  the  IMRD. 
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Rjinge-SidelobeXevel  is  a  real  number  betwe^jn  0  and  50  dB  representing  the  range 
sidelobe  levels  achieved  as  a  result  of  the  pulse  compression  process.  Set  to  25  dB  in 
IMRD. 

NoiseJF'igure  is  a  real  number  between  0  and  10  dB  representing  the  noise  figure  at 
the  receiver  input,  represented  in  db.  Set  to  4  dB  in  the  IMRD. 

Min-InstrumentedJRange  is  a  real  number  between  0  and  100,000  m  representing 
the  minimum  range  of  the  radar  commensurate  with  receiver  blanking  during  trans¬ 
mission.  Set  to  2400  m  in  the  IMRD. 

Beam-Spacing  is  a  real  number  between  0  and  3  representing  the  minimum  spacing 
between  two  adjacent  beams  in  -  space.  Set  to  1  for  IMRD. 

MTI-Loss  is  a  real  number  representing  the  loss  in  the  target  signal-to- noise  ratio 
when  MTI  weighting  is  applied.  Set  to  OdB  in  the  IMRD. 

Active-DwelLTime  is  a  real  number  representing  the  data  collection  time  fer  the 
active  listening  dwell  (CPI2).  Set  to  48e-3  sec  in  the  IMRD. 

PassiveJ3welLTime  is  a  real  number  rej  ’^esenting  the  data  collection  time  for  the 
passive  listening  dwell  (CPU).  Set  to  48c  J  sec  in  the  IMRD. 

MTl-Weights  is  an  array  indexed  by  the  Start  Clutter  Doppler  and  the  End  Clutter 
Doppler  of  the  weather  and/or  ground  interference  found  which  contains  three  records: 
number  of  pulses;  clutter- to-noise  improvement  and  an  index  into  an  MTI  weight 
table. 

Signal-to-interferencc  ratio  (SIR)  is  an  array  indexed  by  probability  of  detection 
(Pd)  and  number  of  looks  whose  elements  contain  signal-to-interference  ratios.  The 
Pd  is  rounded  up  to  the  nearest  .05  and  the  table  and  ranges  from  0.1  Pd  to  0.95. 
The  number  of  looks  ranges  from  1  to  100  and  then  two  additional  rows  represent 
300  and  1000  looks  respectively. 

A. 2  Pascal  Declarations 

Radar  Design  Parameters  are  stored  in  a  Pascal  structure  of  type  design-data_type 
which  is  declared  as  follows. 

const 

MAX.MAX.RANGE.CELLS  -  32; 
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MAX_MAX.POPPLER_CEUS  -  16; 

type 

8ir_pd_index_type  ■  1..18; 

sir_no_looks_, index  ■  1..102; 

sir_array_type  ■  array  [8ir_pd_index_type,  8ir_no_look8_index]  of  real; 

8tart_dop„index„type  ■  -5.. 4; 

end_dop_index..type  ■  -4..  5; 

mti_weight_type  ■ 
record 

No.Pulees  :  non.negative; 

CNI  :  real ; 

Index  :  1..64; 
end; 

azimuth_l;.init,.type  ■ 
record 

Start.Az  :  real; 

End.Az  :  real; 
end; 

eccm_type  ■ 
record 

SL.Blanking.On  :  boolean; 

SL.Cancelliug.ON  :  boolean; 

Freq.Cbauge  :  boolean; 

Circular .Polar  :  boolean; 

end; 

deaign.data.type  « 
record 

Numbtir.Faces 

Number _E1 .Angles 

Azimuth.Limits 

Max.Range.Cells 

Max.Doppler.Cells 

Mzjt.Pass.Dop.Cells 


1.. 4; 

1. . 40; 

azimuth.limit.type; 

1 . . MAX.MAX.RANGE.CELLS ; 

1 . . MAX .MAX.DOPPLER.CELLS; 

1. . 32; 
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Peak.Power 

:  real ;  {W} 

Boresight.Gain 

:  real ; 

Nujnber.of  _Dwells 

o 

o 

Coher_Burs-ts_Per_Dwell 

1.  .16; 

Saniples_Per_PRI 

non.nt^gative; 

Nuinber_of_PRI 

non.negative; 

PRI 

real;  {  seconds  } 

Sigma.Q 

real ; 

MzLX_Radar_Freq_Index 

non.negative; 

Nominal_Radar„Freq 

real;  {  HZ  } 

Radar_Instant_BW 

real;  {  HZ  } 

ECCM_Available 

eccm.type ; 

Sig_To_Jani_Improve 

real ; 

Polar _Rain_Gain 

real ; 

Polar .Target .Loss 

real ; 

MW_Loss_Treais_To_Antenna 

real; 

MW.Loss_Antenna_To_Preamp 

real; 

Signal.Processing.Loss 

real.; 

Freq.Sidelobe.Level 

real; 

Antenna.Sidelobe 

real; 

Sampling.Rate 

real;  {HZ} 

Nom.Target_RCS 

real; 

Nom.Target .Range 

real ;  {m} 

Range.Sidelobe.Level 

real ; 

Noise.Figure 

real ; 

Min.Instrumented.Range 

real;  {m} 

Beam.Spacing 

read;  {(sin(spacing))/ (sinCbeamwidth) )} 

MTI.Loss 

real; 

Act ive.Dwell. Time 

real;  {sec} 

Passive.Dwell.Time 

real;  {sec} 

MTI.Weights 

array [start .dop.index.type, end. dop.index.type] 
of  mti.weight.type; 

SIR  : 

sir.aarray.type ; 

end; 

A. 3  Sample  Input 

The  file,  user3:[digicomp.imrd.data_files]edrp_radar_(lesign.dat  contains  all  the  Radar 
Design  Parameters  except  the  records  MTLWeights  and  SIR.  Shown  below  is  example 
of  the  file  format. 
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1  {  Number.Faces  } 

1  {  Numbor.El ^Angles  } 

-22.5  {  Azimuth.Limita , Start _Az  } 

22.5  {  Azimuth_.limits .End.Az  } 

30  {  Meiz.Range.Cells  } 

16  {  Ma*_Doppler_Cell8  } 

32  {  Majc_Pass_Dop_Cells  } 

100e3  {  Peak.Power  } 

31  {  Bor€8ight_Gain_dB  } 

40  {  Nunber_of_DwGlls  } 

2  {  Coh«r„Burst3_Per_Dwell  } 

900  {  Samples.PRI  } 

16  {  Number.of.PRI  } 

3.0e-3  {  PRI  } 

1.0  -C  Sigma.Q  } 

7  -C  Max_Radar_Freq_Index  } 

5.775o9  {  Nominal „Radar_Freq  )■ 

le6  {  Radar_Instant_BW  } 

true  {  ECCM_Available.SL_Blanking^On  } 

true  {  ECCM_Available.SL_Cancelling„On  } 

true  {  ECCM.Available.Freq.Change  } 

true  {  ECCM_Available. Circular _Polar  } 

0.0  {  Sig_To_Jam_IiaprovG  } 

10  {  Polar _Rain_Gain  } 

7  {  Polar_Target_Lo8s  } 

1.5  {  MW_Loss_Trans_To_Antenna  } 

1.5  {  MW_Loss_Anteniia_To_Preainp  } 

5  {  Sigual.Proceasing.Loss  } 

50  {  Freq.Sidelobe.Level  } 

25  {  Antenna.Sidelobe  } 

le6  {  Sampling.Rate  } 

10  {  Nom_Target_RCS  ) 

40e3  {  Nom_Target_Range  } 

25  {  Range_Sidelobe„Level  } 

4  {  Noise.Figure  } 

2400  {  Min_Xnstnimentod_Range  } 

1  {  Be2un„Spacing  } 

0  {  m.Loas  } 

48e-3  {  Active_Dwell_Time  } 

48e-3  {  Pas8ive_Dwell_Time  } 
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The  MTLWeights  record  is 

contained  in  the  file,  user3:[digicomp.im.rd.data^files]mti_weights.dat.  The  table  is 
shown  below. 


Start  Glut  Dop 


0.3  PRF 
0.2  PRF 
0.2  PRF 
0.1  PRF 
0.1  PRF 
0.1  PRF 
0.0  PRF 
0.0  PRF 
0.0  PRF 
0.0  PRF 
0.0  PRF 
-0.1  PRF 
-0.1  PRF 
-0.1  PRF 
-0.1  PRF 
-0.1  PRF 
-0.2  PRF 
-0.2  PRF 
-0.2  PRF 
-0.2  PRF 
-0.2  PRF 
-0.2  PRF 
-0.3  PRF 
-0.3  PRF 
-0.3  PRF 
-0.3  PRF 
-0.3  PRF 
-0.3  PRF 
-0.3  PRF 
-0.4  PRF 
-0.4  PRF 
-0.4  PRF 
-0.4  PRF 
-0.4  PRF 
-0.4  PRF 


End_Clut_Dop 


0,4  PRF 
0.3  PRF' 
0.4  PRF 
0.2  PRF 
0.3  PRF 
0.4  PRF 
0.0  PRF 
0.1  PRF 
0.2  PRF 
0.3  PRF 
0.4  PRF 
0.0  PRF 
0.1  PRF 
0.2  PRF 
0.3  PRF 
0.4  PRF 
-0.1  PRF 
0.0  PRF 
0.1  PRF 
0.2  PRF 
0.3  PRF 
0.4  PRF 
-0.2  PRF 
-0.1  PRF 
0.0  PRF 
0.1  PRF 
0.2  PRF 
0.3  PRF 
0.4  PRF 
-0.3  PRF 
-0.2  PRF 
-0.1  PRF 
0.0  PRF 
0.1  PRF 
0.2  PRF 


Number  Pulses 


4 

4 

5 

4 

5 

6 
2 

4 

5 

6 
7 
4 

4 

5 

6 

10 

4 

5 

6 

7 

8 
12 

4 

5 

6 

7 

8 

9 

10 

4 

5 

6 

7 

8 

12 


CNI 

Index 

1000 

1 

1000 

2 

1000 

3 

1000 

4 

1000 

5 

1000 

6 

1000 

7 

1000 

8 

1000 

9 

1000 

10 

1000 

11 

1000 

12 

1000 

13 

1000 

14 

1000 

15 

1000 

16 

1000 

17 

1000 

18 

1000 

19 

1000 

20 

1000 

21 

1000 

22 

1000 

23 

1000 

24 

1000 

25 

1000 

26 

1000 

27 

1000 

28 

1000 

29 

1000 

30 

1000 

31 

1000 

32 

1000 

33 

1000 

34 

1000 

35 
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-0.4  PRF  0.3  PRF  16  1000  36 

-0.4  PRF  0.4  PRF  16  1000  37 

The  SIR  record  is  contained  in  the  file, 

user3 :  [digicomp . imrd . data_f  lies]  sir _ea:ray . dat . 

An  example  table  entry  is  shown  below. 

No  PD 


Look 

.10 

.15 

.20 

.25 

.30 

.35 

.40 

.45 

.50 

.55 

1 

5.0 

6.3 

7.6 

9.0 

10.5 

12.2 

14.1 

16.3 

18.9 

22.1 

2 

2.9 

3.6 

4.4 

5.1 

6.0 

7.0 

8.0 

9.3 

10.8 

12.6 

The  table  actually  extends  to  Pds  of  0.95  in  increments  of  0.05.  There  are  100  rows 
corresonding  to  1  through  100  number  of  looks.  Two  additional  row  represent  300 
and  1000  looks  respectively.  The  software  translates  the  indices  accordingly. 
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B  Radar  Environment  Pfirameters 

Radar  Environment  Parameters  describe  the  environment  surrounding  the  radar. 
This  includes  thermal  noise  characteristics  and  ground  and  weather  clutter  maps. 

B.l  Data  Description 

Radar  Environment  Parameters  contain  the  following  components. 

Clutter-Map  is  an  array  of  boolean  variables  which  indicates  where  in  the 
doppler/range  Active-Dwell-Power  array  threshold  crossings  are  expected  if  ground 
clutter  is  present.  There  is  one  array  for  each  beam. 

The  columns  in  the  array  represent  range  samples  in  which  900  samples  are  integrated, 
in  groups  of  30,  down  to  30  colunnms.  The  rows  represent  16  doppler  bins,  each 
separated  by  PRF/16  (21  HZ  in  the  IMRD). 

Weather-Map  is  an  array  of  boolean  variables  which  indicates  where  in  the 
doppler/range  Active_Dwell_Power  array  threshold  crossings  can  be  expected  if 
weather  is  present. 

The  rows  and  columns  have  the  same  interpretation  as  for  the  Clutter-Map. 

Pass-Freq-Thermal-Noise  is  an  array  of  real  values  representing  the  root  mean 
square  (rms)  thermal  noise  in  each  component  of  the  Passive-DwellJFreq-Power  vec¬ 
tors. 

Pass-Range-Thermal-Noise  is  an  array  of  real  values  representing  the  rms  thermal 
noise  in  each  component  of  the  Passive-DwelLRange_Power  vectors. 

Active-Thermal-Noise  is  an  array  of  real  values  representing  the  rms  thermal  noise 
in  each  component  of  the  Active-DwelLPower  vector. 


B.2  Pascal  Declarations 

The  Radar  Environment  Parameters  are  stored  in  a  Pascal  structure  of  type 
radar_environment-type  which  is  declared  as  follows: 
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type 


beam.type 

doppler_cell_type 

pass_dopp_cell_type 

range.cell^type 

thresh^crossing.type 


-  1. .MAX.BEAMS; 

»  1. .MAX_MAX_DOPPLER_CELLS; 

-  1..32; 

-  1. .MAX_MAX_RANGE.CELLS; 

■  array  [doppler_cell_type,r2inge_cell_type] 


of  boolean 


spectrum.type  »  array [doppler_cell .type,  range.cell.type]  of  real; 


radar.environnent.type  ■ 
record 

Clutter.Map 
Weather .Map 

Pass.Freq.Thermal.Noiae 
Pass  .Rainge  .Thermal  .No  i  s  e 
Active„Thermal_Noise 
6Bd; 


arraj [beam.type]  of  thresh.crossing.type; 
thresh.crosising.typc ; 
array  [pass.dopp.cell.type]  of  real; 
array  [range.cell.type]  of  real; 
spectrum.type; 


B.3  Sample  Input 

Three  files  in  the  directory  user3:[digicoinp.imrd.baselineJ}.data_files]  contain  all  the 
Radar  Environment  Parameters.  The  Clutter  .Map  array  is  contained  in  the  file 
edm.ground_clutterjnaT).dat  and  contains  a  boolean  array  for  each  beam  as  shown 
below.  The  map  is  organized  as  rows  representing  decreasing  doppler  indices  (1  to  16 
bins)  and  columns  representing  increaising  range  indices  (1  to  30  range  values). 

Note  that  in  the  sample  map,  ‘trues’  occur  only  in  the  first  and  last  rows  (ground 
clutter  is  assumed  to  be  zero  mean)  and  only  out  to  the  7th  range  cell  (ground  clutter 
is  normally  visible  to  the  radar  horizon).  Moreover,  the  first  range  cell  has  been 
excised  because  of  transmitter  blanking  at  this  cell  location. 

Beam  Number  ■  1 

fttttttfffffffffffffffffffffff 

ffffffffffffffffffffffffffffff 

ffffffffffffffffffffffffffffff 

ffffffffffffffffffffffffffffff 

ffffffffffffffffffffffffffffff 

ffffffffffffffffffffffffffffff 

ffffffffffffffffffffffffffffff 

ffffffffffffffffffffffffffffff 
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The  Weather-Map  array  is  filled  from  the  file  mdr_data;edm_weather_map.dat  and 
contains  the  boolean  map  as  shown  below.  The  map  is  organized  as  rows  representing 
decreasing  doppler  indices  (1  to  16  bins)  and  columns  representing  increasing  range 
indices  (1  to  30  range  values). 


Note  that  in  this  map  ‘trues’  occur  only  after  the  7th  range  cell  (it  was  necessary 
to  excise  cells  1  through  7  to  remove  doppler  sidelobes  of  close-in  ground  clutter). 
The  ground  clutter  also  made  it  necessary  to  excise  three  rows  straddling  the  DC  bin 
because  of  ground  clutter  leakage. 
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The  thermal  noise  record,  Pass_Freq_Thermal_Noise,  Pass_Range_ThermaLNoise  and 
Active_DwelLThermal_Noise  records  are  filled  from  the  file  edm_thermal_noise.dat. 
Shown  below  are  representative  portions  of  the  file  showing  the  format  used  for  each 
record.  This  file  can  be  automatically  generated  from  Beam  Scan  Data  saved  by 
the  Adaptive  Control  software.  The  logical  beam_scan_data  must  be  assigned  to  the 
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file  you  wish  to  convert.  Then  switch  to  directory,  mdr.data,  and  run  the  program, 
convert_thermal_noise. 

The  Pass_Freq_ThermaI_Noise  data  is  the  filled  first  and  has  the  following  format: 

PASS  DOPP  PFV 

INDEX 

1  3093.907227 

2  617.143372 

3  515,613281 

4  361.361664 


The  Pass_Range_Thermal_Noise  data  is  separated  from  the  Pciss-Freq_ThermaLNoise 
data  by  a  blank  line  and  hais  the  following  format: 


RANGE 

PRV 

INDEX 

1 

112.330116 

2 

112.330116 

3 

112.330116 

4 

112.330116 

PRSV 


The  ActiveJDwelLThermal-Noise  data  is  separated  from  the 
?a!5:H..Range_Therrnal-Noise  data  by  a  blank  line  and  has  the  following  format: 


IT.'-PPLER 

RANGE 

ASA 

INDEX 

1 

INDEX 

1 

673.622131 

1 

2 

673.622131 

1 

3 

673.622131 

1 

4 

673.622131 

ASSA 


For  more  information  including  complete  data  formats  see  the  appropriate  files. 
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C  Priority  Zone  Parameters 

Regions  under  radar  surveillance  can  be  partitioned  into  Priority  zones  based  on  the 
expected  importance  of  maintaining  detection  within  them.  The  IMRD  allows  for 
five  different  levels  of  Priority  Zone  and  is  able  to  allocate  scan  time  by  level.  The 
Priority  Levels  in  decreasing  order  of  importance  are:  high  threat;  medium  threat; 
low  threat;  friendly;  and  unoccupied. 


C.l  Data  Description 

Priority  Zones  are  delimited  by  start  azimuth,  stop  azimuth,  near  range,  and  far 
range; 

Az.Start:  Azimuth  start  angle  in  degrees. 

AzJBnd:  Azimuth  end  angle  in  degrees. 

Near-Range:  Start  range  zone  in  meters. 

Far-Range:  End  range  zone  in  meters. 

Threat:  The  zone  priority. 

These  are  eisserted  into  the  Prolog  database  £is  fact  priority  .zone.  Consistency  checks 
are  made  to  assure  that  no  region  is  assigned  more  than  one  priority.  A  default  level 
of  “unoccupied”  is  assigned  to  any  region  that  is  unassigned. 


C.2  Sample  Input 

Priority  Zone  data  can  be  entered  interactively  online  or  read  from  a  file.  The 
file  contains  a  single  line  for  each  zone.  The  default  priority  zone  file  name  is 
user3:  [digicomp.imrd.data_filesJpriority_2one.dat  and  an  example  is  shown  below. 

priority_zone(-22.5,  22.5,  0,  5000,  high_threat) . 
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D  Quality  Options 

Quality  Options  define  a  set  of  operating  plans  to  be  used  to  allocate  scan  time  to 
beams  in  the  surveillance  region.  There  can  be  at  most  eight  assigned  plans  with  the 
first  plan  allowing  the  best  performance  and  the  last  plan,  the  worst.  Each  plan  states 
the  desired  probability  of  detection,  the  passive  dwell  update  rate  and  the  active  dwell 
update  rate  for  each  of  the  five  types  of  threat  zone  defined  by  the  Priority  Zone  facts. 

The  desired  probability  of  detection  is  stated  for  each  Priority  Zone  within  each  plan. 
Normally,  it  will  be  higher  for  the  higher  Priority  Zones,  and  will  decrease  for  the 
higher  plan  numbers. 

The  passive  and  active  update  rates  which  specify  how  frequently  passive  and  active 
dwells  for  each  beam  should  be  repeated  in  each  plan.  In  the  IMRD  configuration 
the  maximum  passive  dwell  update  rate  and  the  maximum  active  dwell  update  rate 
is  one  (meaning  every  beam  should  have  an  passive  and  active  detection  dwell).  This 
is  because  the  Radar  Controller  code  is  .set  up  to  always  include  passive  and  active 
dwells,  but  a  future  version  of  the  IMRD  may  allow  these  rates  to  vary. 

The  Adaptive  Controller  will  select  the  first  plan  that  caji  execute  within  the  desired 
scan  time.  If  no  one  of  the  plans  can  execute  within  the  desired  scan  time,  a  default 
plan  (nine)  assigns  all  dwell  time  to  the  highest  priority  zone  so  as  to  achieve  the 
highest  Pd  within  it. 

D.l  Data  Description 

The  Quality  Options  Tables  are  constructed  from  the  following  component: 

quality _option_entry:  assigns  the  probability  of  detection  and  update  rates  for  CPIs 
1  and  2  to  a  priority  level. 

•  Pd;  the  probability  of  detection. 

*r  cpLupdate-rate:  a  record  with  CPU  and  CPI2  update  rates. 

There  is  one  quality_option_entry  for  each  Priority  Zone  and  for  each  of  the 
eight  plans. 

D.2  Pascal  Declarations 

The  Quality  Option  Tables  are  stored  in  Pascal  data  structures  which  are  declared 
as  follows: 


Quality  Options 
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type 

no_of  _of>tions_type  *  1 . .  (MAX_NO_OPTIONS  +  1); 

cpi_updatG_rate  » 
record 

Passive  :  0. .MAX_PASSIVE_UPDATE_RATE; 

Active  :  0. .MAX_ACTIVE_UPDATE_RAT£; 
end; 

quality_option_entry  = 
record 

Pd  :  real ; 

Rate  :  cpi_update_rate; 
end; 

quality_options_table_line  *  array  [no.of _options_type]  of 

quality_option_entry ; 


quality.options.table 


record 

High 

Med 

Lou 

Friendly 

Unoccupied 

end; 


quality_options_tabl0_line ; 
quality.options_table„line ; 
quality„options_table_line; 
quality_options_table_line; 
quality_options_table_line; 


D.3  Sample  Input 

The  file  user3:[digicomp.imrd.dataJiles]quality _options.dat  contains  the  default  qual¬ 
ity  option  table  shown  below. 

Probability  Detection  Table 
Quality.Options 

Priority .Level  1234567  8 

High  threat  0.9  0.9  0.9  0.9  0.9  0.9  0.5  0.5 
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Medium  threat 

0.9  0.9 

0.9 

0.7 

O.t' 

0, 

0.3 

0.0 

Low  threat 

0.9  0.9 

0.7 

0.5 

0.5 

0.3 

0.0 

0.0 

Friendly 

0.9  0.7 

0.5 

0.5 

0 . ' 

0,0 

0.0 

0.0 

Unoccupied 

0.9  0.5 

0.5 

0.3 

P .  0 

o.c 

0.0 

0  0 

Passive 

1  Update  Rale 

Table 

Quality .Opt ions 

Priority .Level 

1  2 

3 

4 

5 

6 

7 

.  8 

High  threat 

1  1 

1 

1 

1 

1 

1 

1 

Medium  threat 

1  1 

1 

1 

1 

1 

1 

1 

Low  threat 

1  1 

1 

1 

4 

1 

1 

S 

Friendly 

i  1 

1 

1 

1 

1 

1 

1 

Unoccupied 

1  1 

1 

1 

1 

1 

1 

1 

Active 

Update 

Rsit' 

Table 

Quality. Op tioas 

Priority .Level 

1  2 

3 

4 

5 

(5 

7 

8 

High  threat 

1  1 

1 

1 

.t 

1, 

1 

1 

Medium  threat 

1  1 

1 

i 

1 

1 

1 

1 

Low  threat 

1  1 

1 

/ 

A 

1 

1 

Friendly 

1  1 

1 

1 

1 

1 

3 

Unoccupied 

1  1 

1 

1 

1 

1 

1 

1 
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E  AI  Control  Parameters 

A I  Control  Parametcru  are  a  set  of  Prolog  facts  through  which  the  user  can  customize 
the  Adaptive  Control  software  capabilities. 


E.l  Data  Description 

A I  Control  Parameters  contain  the  following  components: 

desired-Bcan.time  is  the  maximum  time  desired  for  a  single  scan  of  the  surveillance 
region.  This  is  then  used  by  the  Allocate  Radar  Resources  subproblem.  The  argument 
of  this  fact  is  a  floating  number. 

scanJnput.mode  indicates  whether  the  Adaptive  Controller  receives  data  from  and 
sends  data  to  the  radar  or  the  stand-alone  FRDE.  The  allowed  value  for  the  argument 
is  the  atom  “frde”  or  “radar.” 

ai.on  indicates  whether  the  Adaptive  Controller  will  change  Radar  Control  Parame¬ 
ters  from  scan  to  scan  or  will  use  the  same  default  parameters  each  time.  In  this  later 
case  the  primary  purpose  of  the  Adaptive  Controller  is  to  identify  any  interferences 
present  in  the  scan.  The  allowed  value  for  the  argument  is  the  atom  “yes”  or  “no.” 

operating-mode  indicates  whether  the  program  is  suspended  at  the  end  of  a  scan 
automatically  for  user  input  (manual)  or  whether  execution  continues  until  the  user 
requests  suspension  (automatic). 

use-highest-quality^ption  indicates  whether  the  highest  quality  option  should  al¬ 
ways  be  used  regardless  of  scan  time.  The  allowed  value  for  this  argument  is  the  atom 
“yes”  or  “no.” 

eccm^n  indicates  which  ECCM  the  user  desires  to  use.  Note  that  only  those 
ECCM  for  which  the  corresponding  Radar  Design  Parameter  record  indicates  are 
available  will  be  enabled.  The  allowed  values  for  this  argument  are  the  atoms  fre¬ 
quency-hopping,  sidelobe-blanking,  sidelobe-cancelling  and  circular-polari/ation. 


E.2  Sample  Input 

These  Prolog  facts  can  be  entered  online  or  from  a  file.  The  file  should  contain  one 
fact  per  line.  The  default  tile  is  user3:[digicomp.itnrd.data-Rle8]ai-control.dat  and  is 
shown  below. 
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op«rating_mode(  autonatic  ). 

8 can. input .mode (  radar  ) . 
desired.scan.timeC  10  ). 
ai.onC  y  ) . 

use.highest.quality.optionC  no  ) 
eccm.onC  frequency .hopping  ) . 
eccm.onC  sidelobe.canceller  ) . 
eccm.onC  sidelobe.blanker  ) . 
eccm.onC  circular .polarization  ) 
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F  AI  Output  Parameters 

AI  Output  Parameters  are  a  set  of  Prolog  facts  which  allow  the  user  to  customize  the 
type  and  destination  of  output  displays. 


F.l  Data  Description 

AI  Output  parameters  contain  the  following  components: 

user-display  is  used  to  display  data  which  is  a  final  output  product  of  the  Adap¬ 
tive-Controller  software.  The  fact  has  a  two  part  argument  with  the  first  atomic 
argument  indicating  the  type  of  data  and  the  second  atomic  argument  indicating  the 
data  destination.  The  possible  values  of  the  first  argument  are:  “inierferenceJd” , 
which  identifies  which  interferences,  along  with  its  parameters,  were  found  for  ev¬ 
ery  beam;  “quality-option.used”,  which  shows  which  quality  option  plan  was  chosen 
for  the  next  scan;  “ai-results”,  which  displays  the  dwell  time,  interferences  identified 
and  eccms  applied  for  each  beam  in  the  scan;  and  “radar_controls” ,  which  displays 
the  radar  controls  sent  to  the  HP2117F.  The  second  argument  can  have  two  values, 
“screen”  and/or  “file”.  Note  that  radar_controls  can  only  be  sent  to  a  file  due  to  the 
verbose  nature  of  this  output.  If  file  is  chosen  as  destination,  the  data  will  go  to  a 
file  whose  name  is  the  first  argument  followed  by  the  file  extension  “.out”. 

diagnostic-output  is  used  to  display  intermediate  data  and  is  normally  used  for 
debugging  or  data  analysis.  The  atomic  argument  can  have  three  values  repre¬ 
senting  three  data  types:  “beam_scan-data”,  the  data  being  sent  by  the  ST-100; 
“radar-parameters-array” ,  the  output  of  the  Determine-Applicable-ECCM  subprob¬ 
lem;  and  “beamJnfo”,  the  data  structure  which  combines  the  priority-zone  and  qual¬ 
ity-options  data  structure.  These  data  structures  can  only  be  sent  to  a  file.  The  files 
name  is  the  argument  followed  by  the  file  extension  “.out”. 


F.2  Sample  Input 

These  facts  can  be  entered  onhne  or  using  a  file.  Each  line  in  the  file  should  contain 
one  prolog  fact.  The  default  file  is  user3:[digicomp.inud. data_filesjai-output.dat  and 
is  shown  below. 

usar_display(  quality.option.used,  screen  ). 
user.displayC  ai.results,  screen  ). 
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G  Beam  Scan  Data 

Beam  Scan  Data  contains  the  beam  by  beam  data  used  by  the  Adaptive  Controller  to 
perform  the  adaptive  control  process.  This  data  is  trainsferred  for  each  search  beam 
in  a  scan  from  the  radar  environment  through  the  ST-lOO  to  VAX/VMS  mailboxes. 


G.l  Data  Description 

Inputs  from  the  ST-lOO  to  the  VAX  Adaptive  Controller  will  be  in  the  form  of  Beam 
Scan  Data,  a  record  which  consists  of  the  following: 

Frame-Count  is  an  integer  representing  the  frame  count  of  the  current  scan.  The 
frame  count  starts  at  1  for  the  first  frame  and  is  incremented  by  1  for  each  successive 
scan. 

Beam-Id  is  an  integer  representing  the  betim  within  the  current  frame  (scan).  It 
starts  at  1  for  the  first  beam  in  the  scan  and  is  incremented  by  1  for  each  successive 
beam. 

Passive-Dwell-Range-Power  is  an  array  of  real  numbers  whose  components  contain 
the  average  power  level  returned  from  the  passive  listening  dwell  for  consecutive 
integrated  range  cells  in  each  of  8  PRIs. 

PassivcJDwell-Range-Var  is  an  array  of  real  numbers  whose  components  contain  the 
vaiiabililty  of  the  power  level  returned  from  the  passive  listening  dwell  for  consecutive 
integrated  range  cells  in  each  of  8  PRIs. 

PassiveJDwelLFreq-Power  is  an  array  of  real  numbers  whose  components  contain 
the  FFT  of  each  Passive_DwelLRange_Po-  t  vector  for  each  PRI,  with  each  s;.  ,  ie 
representing  a  block  integration  of  32  magnitude-detected  FFT  output  samples. 

Active-Dwell  J*ower  is  an  array  of  real  numbers  whose  components  represent  the 
doppler  filter  bank  calculated  over  the  16  PRIs  of  the  active  listening  dwell,  and 
integrated  in  blocks  of  30  r<uige  cells. 

Active-Dwell-Var  is  an  array  of  real  numbers  whose  components  contain  the  square 
of  the  Activc-DwellJPower  array. 

Sidelobe-Sum  is  an  integer  array  representing  the  number  of  samples  where  sidelobe 
jamming  was  sensed  by  the  sidelobe  blanking  circuit  in  the  passive  listening  dwell  for 
each  PRI. 


Beam  Scan  Data 
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G.2  Pascal  Declarations 

The  BeAm  Scan  Data  are  stored  in  a  Paiscal  structure  of  type  beam_scan-data„type 
which  is  declared  as  follows: 


type 


frame.type 

beam.type 

range.cell.type 

pas3_dopp_cell_type 

doppler.cell _type 

no_pri 


1.. MAX_INTEGER; 

1 . . MAX_NO„BEAMS ; 

1..  MAX_MAX_RANGE.CELLS; 

1. . 32. 

1 . . MAX.MAX.DOPPLER.CELLS; 

1.. MAX_PRIS; 


range.type 

freq_type 

spectrum^type 


array  [no.pri ,range_cell_type]  of  real; 

array  [no_pri,pass_dopp_cell_type]  of  real; 

array  Cdoppler_cell_type,rauige_cell_type]  of  real; 


beam_8can_data_type  ■ 
record 

Frame„Count 

Beasi.Id 

Passive _Dwell_Range_Power 
Passive  _Dwell_Range_V air 
Pass ive.Dwell _Freq_Power 
Act i ve.Dwell .Power 
Active.Dwell.Var 
Sidelobe.Suffl 
end; 


frane.type;  {  Scan  number  } 

beao.type;  {  Which  beam  within  the  scan  > 

range .type ; 

range.type; 

freq.type; 

spectrum.type; 

spectrum.type ; 

array  [no.pri]  of  integer; 
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H  Radar  Control  Parameters 


Radar  Control  Parameters  contain  the  beam  by  beam  data  used  to  control  the  radar 
for  the  next  scan.  They  are  transfered  from  the  VAX  to  the  HP2117F  Radar  Con¬ 
troller  via  the  IEEE-488  bus  interface.  All  records  are  two  byte  words. 

H.l  Data  Description 

Radar  Control  Parameters  contain  the  following  components: 

Last-Beam  is  a  boolean  variable  indicating  whether  the  current  beam  is  the  letst 
beam  control  record  for  the  current  scan. 

Face-Index  is  an  integer  representing  the  radar  face  index  for  the  current  beam 
position.  Within  the  IMRD  the  value  is  always  1,  but  the  variable  is  included  to 
allow  the  possibility  of  generahzing  to  other  radtir  environments.  It  can  assume 
values  between  1  and  4. 

Azimuth-Index  is  an  integer  indicating  the  azimuth  angle  for  the  current  bea 
position.  This  value  is  represented  to  the  HP  by  an  integer  between  0  and  9000  w-t 
0  corresponding  to  -45  degrees  and  9000  corresponding  to  -t-45  degrees. 

Elevation-Index  is  an  integer  indica  the  elevation  angle  for  the  current  beam 
position.  It  can  assume  values  between  0  and  40  degrees.  Within  the  IMRD  the 
value  is  always  0,  but  the  viable  is  included  to  allow  the  possibility  of  controlling 
this  variable  from  the  rulebase. 

Trans-Center  .I  req  's  an  integer  variable  indicating  which  frequency  to  use.  The 
softwtire  can  r  rod-l  up  to  16  unique  frequencies,  however  the  IMRD  system  will  only 
use  eight.  This  in.ieA  is  then  translated  by  the  HP2117F  to  a  real  frequency  value. 

ECCMs-On  is  a  record  variable  where  each  record  is  a  boolean  variable  which  indi¬ 
cates  whether  the  given  ECCM  should  be  on.  The  components  are: 

•  Sidelobe-Blanking 

•  Sidelobe-Cancelling 

•  CFAR 

PRI  is  an  integer  representing  the  pulse  repetition  interval  in  microseconds  to  use  for 
the  beam  position.  It  can  assume  values  between  1  and  4096.  Within  the  IMRD  the 
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value  is  always  3000,  but  the  variable  is  included  to  allow  the  possibility  of  controlling 
this  variable  from  the  rulebase. 

PulseJDuration  is  an  integer  representing  the  pulse  duration  for  the  beam  position. 
It  can  assume  values  between  0  and  40  microseconds.  Within  the  IMRD  the  value 
is  always  16,  but  the  variable  is  included  to  allow  the  possibility  of  controlling  this 
variable  from  the  rulebase. 

Pulse_Band width  is  an  integer  representing  the  pulse  bandwidth  for  the  beam  po¬ 
sition.  It  can  assume  values  between  0  and  10  MHz.  Within  the  IMRD  the  value 
is  always  1,  but  the  variable  is  included  to  allow  the  possibility  of  controlling  this 
variable  from  the  rulebase. 

TX-Polarization  is  an  enumerated  variable  representing  the  antenna  polarization  to 
use  for  transmitting  in  the  beam  position.  Possible  values  include  Horizontal,  Vertical, 
Left.Circular,  and  Right_Circular. 

RX-Polarization  is  an  enumerated  variable  representing  the  antenna  polarization  to 
use  for  receiving  in  the  beam  position.  Possible  values  include  Horizontal,  Vertical, 
Left-Circular,  and  Right-Circular.  Within  the  IMRD  the  value  is  always  Horizontal, 
but  the  variable  is  included  to  allow  the  possibility  of  controlling  this  variable  from 
the  rulebase. 

AdaptiveJMTL. Weights  is  an  integer  representing  which  of  64  possible  MTI  weights 
sets  to  be  used  in  a  particular  beam  position.  In  the  IMRD,  37  unique  sets  are  used 
with  the  number  64  representing  the  default  “all  pass”  weight  set. 

DwelLTime-per-Look  is  an  integer  representing  the  PRI  of  CPI3.  The  values  can 
range  from  1  to  1000  msec.. 

Number-ofLLooks  is  an  integer  representing  the  number  of  PRIs  to  be  used  in  CPIS. 
The  values  can  range  from  0  (indicating  the  beam  should  be  skipped)  to  10000; 

Passive-Dwell-On  is  a  boolean  variable  indicating  whether  CPI  1  should  be  skipped. 
Within  the  IMRD  the  value  is  always  true,  but  the  variable  is  included  to  cillow  the 
possibihty  of  controlling  this  variable  from  the  rulebase. 

Active-Dwell-On  is  a  boolean  variable  indicating  whether  CPI  2  should  be  skipped. 
Within  the  IMRD  the  value  is  always  true,  but  the  variable  is  included  to  allow  the 
possibility  of  controlling  this  variable  from  the  rulebase. 
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H.2  Pascal  Declarations 

The  Radar  Control  Parameters  are  stored  in  a  Pascal  data  structure  which  is  declared 
as  follows: 


type 


face_index_type 

polaxization.type 

azimuth.angle.type 

center_freq_type 

pri.type 

pulse.duration.type 
pulse_bw_type 
adapt  _mt i .type 
dwell.time.type 

no.looks.type 


[WORD]  1..4; 

[WORD] 

(Right .Circular,  Vertical,  Left. Circular,  Horizontal); 
[WORD]  0 . . 9000 :  {  range  from  -45 . 0  to  +45  <  0  degrees  } 
[WORD]  1..15;  {  One  of  15  center  frequencies  } 

[WORD]  1..4096;  {  Microsec  } 

[WORD]  0..40;  {  Microsec  } 

[WORD]  0..10;  {  MHz  } 

[WORD]  1..64;  {  one  of  64  weight  sets  } 

[WORD]  0.  000;  {  Dwell  time  will  range  from 

1  msec  to  1  sec  } 

[WORD]  0.  ^000; 


eccm.controls.type  ■ 
record 

Sidelobe.Blanking  : 
Sidelobe.Cancelling  : 
CFAR  : 

end; 

control_data. ‘ : pe  ■ 
record 
Last .Beam 
Face .Index 
Azimuth.Angle 
Elev.Index 
Trans.Center.Freq 
ECCMs.On 
PRI 

Pulse. Duration 
Pulse.Bandwidth 
Tx.Polarization 
Rx.Polar izat ion 
Adapt ive.MTI .Weights 
Dwell .Time .per .Look 


[WORD]  boolean; 
[word!  boolean; 
[WORD,  boolean; 


[WORD]  boolean; 

face.index.type;  {  index  of  active  face} 

azimuth.zmgle.type;  {  index  of  azimuth  angle} 

[WORD]  non.negative;  {  index  of  elevation  auigle} 

center.f req.type ;  {  center  frequency  in  Mhz  } 

eccm.controls.type , 

pri.type;  {  Micro sec  } 

pulse.duration.type;  {  Microsec  } 

pulse.bw.type;  {  MHz  } 

polarization.typa ; 

polarization.type ; 

adapt .mti.type ; 

dwell .t ime.type ; 
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Number.of .Looks 
Passive.Ovell.On 
Active.Dwell.On 
end;  {control.data.type} 


no.looks.type; 
[WORD]  boolean; 
[WORD]  boolean; 
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I  AI  R^uiebases 

I.l  Introduction 

Tbjs  appendix  documents  the  expertise  which  is  incorporated  into  the  Adaptive  Con¬ 
trol  software  developed  under  the  Integrated  Multi-Domain  Radar  Demonstration, 
Contract  ^F30602-89-C-0045.  This  set  of  rules  evolved  during  the  contract  and  per¬ 
form  well  in  the  RLSF  environment,  but  can  be  expected  to  evolve  with  further  system 
experimentation  and  if  transported  to  other  radar  environments.  This  evolution  is 
facilitated  by  software  organization. 

The  Adaptive  Control  software  resides  on  a  VAX  8650  and  performs  the  IMRD  Adap¬ 
tive  Control  function.  It  accepts  the  Beam  Scan  Data  for  each  beam  in  a  surveillance 
regioii  and  determines  what  control  changes  should  be  made  for  each  beam  during 
the  next  Sf;an.  At  the  end  of  each  scan,  Radar  Control  Parameters  for  each  beam  in 
th  ‘  :ieyt  scan  ate  sent  to  the  Radar  Controller  (HP2117). 

litput.'?  to  the  Avdaptive  Controller  are  organized  into  the  following  data  structures: 

Parameters  which  describe  the  radar  configuration  including 
pax^r\ctr^rs  as  the  number  of  beam  dwell  positions  per  scan  and  the  avail- 
xib'e  ECCM  See  Appendix  A.3  for  a  description  of  this  data. 

2.  Jtadar  Itiavironment  Parameters  which  describe  the  radar  environment  includ¬ 
ing  such  parameters  as  thermal  noise  characteristics  and  ground  and  weather 
clutter  maps  used  to  identify  candidate  positions  for  interference  in  the  active 
dwell.  See  Appendix  B.3  for  a  description  of  this  data. 

3.  Priority  Zone  Parameters  which  map  threat  levels  to  specific  scan  regions. 
See  Appendix  C.2  for  a  description  of  this  data. 

4.  Quality  Options  which  describe  quality  plans  to  be  used  to  allocate  dwell  time 
to  beams  in  the  next  scan  so  as  to  maximize  probability  of  target  detection 
subject  to  Priority  Zone  constraints.  See  Appendix  D.3  for  a  description  of  this 
data. 

5.  AI  Control  Parameters  which  control  various  modes  of  program  operation. 
See  Appendix  E.2  for  a  description  of  this  data. 

6.  AI  Output  Parameters  which  describe  the  types  and  destinations  of  output 
produced  during  Adaptive  Controller  execution.  See  Appendix  F.2  for  a  de¬ 
scription  of  this  data. 

7.  Beam  Scan  Data  which  contains  data  from  passive  and  active  listening  dwells. 
This  is  read  and  processed  on  a  beam-by-beam  basis  for  each  beam  in  a  surveil¬ 
lance  region.  See  Appendix  G.2  for  a  description  of  this  data. 
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The  artificial  intelligence  is  embodied  in  an  Adaptive  Control  AI  Engine  which  is 
organizxjd  into  the  following  rulebases: 

1.  ID  Passive  Interference; 

2.  ID  Active  Interference; 

3.  Determine  Applicable  ECCM;  and 

4.  Allocate  Radar  Resources 

cis  shown  in  Figure  I-l. 

ID  Passive  Interference  computes  discriminant  values  from  the  passive  listening 
vectors  of  the  Beam  Scan  Data.  These  are  used  to  determine  the  presence  of  CW 
and  pulsed  jammers.  If  a  jammer  is  found,  the  peek  jammer- to- noise  ratio  (JNR), 
the  range  c.ell  of  the  jammer,  and  the  mainlobe  duty  factor  are  reported. 

ID  Active  Interference  computes  discriminant  values  from  the  active  listening  arrays 
of  the  Beam  Scan  Data.  These  are  used  to  detect  weather  and  ground  clutter.  If  active 
interference  is  identified,  the  peak  clutter-to-noise  ratio  (CNR),  the  peak  clutter  to 
noise  ratio  at  the  maximum  range  of  the  clutter,  the  maximum  range  of  the  clutter, 
and  the  doppler  extent  of  the  clutter  are  reported. 

Determine  Applicable  ECCM  analyzes  the  interference  identifications  and  ranks 
plans  that  counteract  the  interference  by  increasing  probabilities  of  target  detection. 

Allocate  Radar  Resources  uses  the  plans  developed  by  Determine  Applicable  ECCM 
along  with  user-assigned  Priority  Zones  and  Quality  Options  to  select  the  best  oper¬ 
ating  plan  that  meets  the  user-desired  scan  time. 


1.2  Initialization  Procedures 

Several  initialization  procedures  translate  system  configuration  inputs  into  values  that 
are  used  directly  by  the  A!  Engine  software.  By  calculating  these  values  at  system 
initialization  and  then  saving  them  in  global  Pascal  variables  computation,  time  is 
saved  during  real-time  processing  of  incoming  Beam  Scan  Data. 

1.2.1  Inputs 

The  inputs  to  initialization  procedures  include  the  Radar  Design  Parameters  and 
Radar  Environment  Parameters,  mentioned  in  Section  I.l  and  described  in  Appen¬ 
dices  A. 3  and  B.3. 


AI  Rulebases 


125 


1.2.2  Processing 

The  following  are  calculated  during  system  initialization. 

Normalization  Constants:  Normalization  constants  are  used  to  calculate  variability 
of  the  ActiveJDwell-Power  array  over  a  given  map.  The  constants  are  calculated  as 
follows: 

for  RangeJndex  =  1  to  Max-Hange-CeUs  do 

t  =  Range-Index  —  1 

Ro  =  IG^sec  *  150-^^  =  2400 
fisec 

((RangeJndex  —  1)  ♦  C  ♦  30e  -  6) 

Hi  =  Ho  + - - - 

The  Passive-Range-Threshold  vector  is  calculated  by  multiplying  the  passive  range 
thermal  noise  vector  by  2. 

The  Active.J)well-Threshold  array  is  calculated  by  multiplying  the  active  dwell 
thermal  noise  array  by  3. 

The  Per-Pulse-SNR  is  calculated  from  Radar  Design  Parameters  for  a  user-specified 
t2u:get  RCS  and  detection  range. 

Beam  Scan  Data  is  indexed  from  1  to  Number_ofJDwells  as  opposed  to  by  actual 
akzimuth  angle.  The  azimuth  angle  corresponding  to  each  beam  is  calculated  and 
inserted  into  the  Scan-Radar-Control  data  structure. 

1.2.3  Outputs 

The  constants  csJculated  at  initialization  arc  saved  in  the  following  global  Pascal  data 
structures: 

•  Norm_Const[O..MaxJlange-Cells  -  1] 

•  Pas8ive-Range_Threshold[l  ..Max-Range-Cells] 

•  Active_DwelLThre8hold[l..Max-Doppler-Cell8,l ..Max-Range-Cells] 

•  Per-Pulse-SNR 

•  Scan-Radar-Controls[l..Number-of-Dwells].  Azimuth-Angles 
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1.3  ID  Passive  Interference  Rulebase 


ID  Passive  Interference  identifies  the  following  categories  of  jammer: 


Wideband  CW  Mainlobe 

Wideband  CW  Sidelobe 

Narrowband  CW  Mainlobe 

Narrowband  CW  Sidelobe 

Wideband  Asynchronous  Pulsed  Mainlobe 

Wideband  Asynchronous  Pulsed  Sidelobe 

Narrowband  As}rnchronous  Pulsed  Msiinlobe 

Narrowband  Asynchronous  Pulsed  Sidelobe 

W'ideband  Unknown 

Narrowband  Unknown 


The  ID  Passive  Interference  rulebase  takes  the  passive  listening  component  of  Beam 
Scan  Data  as  input.  The  passive  rules  determine  if  a  jammer  is  present  and  the  i 
determines  its  type.  If  a  match  is  found,  the  jammer  type  as  well  as  the  peak  JNR,  tne 
jammer  range,  and  the  mainlobe  duty  factor  are  asserted  with  the  beam  identification 
number  as  facts  into  the  Prolog  database. 


1.3.1  Inputs 

The  specific  components  of  Beam  Scan  Data  that  are  used  in  ID  Passive  Interference 
are: 

•  Pa88ive_Dwe'Ln.ingeJPoweri  an  array  whose  components  conteun  the  average 
voltage  magnitude  returned  from  the  passive  listening  dwell  for  consecutive 
range  cells  in  each  of  8  PRls. 

•  Passive-DwelLRange-Var:  an  array  whose  compon onts  contain  the  power  level 
returned  from  the  passive  listeni.  dwell  for  consecutive  range  cells  in  each  of 
8  PRIs. 

•  Passive-PrequencyJPower:  an  array  whose  components  contain  the  FFT  of 
the  range  samples  returned  from  the  passive  listening  dwell  for  consecutive 
frequency  bins  in  each  of  8  PRIs. 
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•  SidelobeJSum:  an  integer  array  whose  components  represent  the  number  of 
samples  in  the  passive  listening  dwell  v;here  sidelobe  jamming  is  sensed  for  each 
of  8  PRIs. 

Due  to  transmitter  leakage,  the  first  range  cell  in  PassiveJDwell-Range-Power  and 
Pas8ive_Dwell-Range-V£u-  is  excised  from  any  determinate  or  parameter  calculations. 

The  variable  PassJlange-ThermaLNoise  calculated  during  initialization  is  also  used. 


1.3.2  Processing 

1.3.2. 1  Determine  Jammers  Present  The  Threshold  Crossings  Ratio  is  u.sed  to 
determine  if  a  jammer  is  present  in  the  current  beam.  It  is  calculated  by  counting  the 
number  of  elements  in  the  Passive_DwellJflange_Power  array  which  exceed  the  corre¬ 
sponding  element  in  Passive-Range-Threshold  vector  and  dividing  by  the  total  num¬ 
ber  of  array  elements  (8  Max-Range-Cells).  It  is  denoted  cis  Thresh-Cross-Ratio. 

The  rule  to  determine  the  presence  of  januners  is: 


IF 

Thr«8h_Cro88_Ratio  >0.0 

THEN 

JaBBars  sire  present. 

Go  to  Identify  Jaaner  Type  Rules. 


ELSE 

No  j  asBers  sure  present . 

Exit  Id  Passive  Interference  subproblem. 


1.3.2. 2  Identify  Jammer  Type  The  peak  and  average  value  of  the  Pas- 
sive-DwciLRange_Power  vector  are  calculated  for  each  PRI  and  used  as  inputs  to 
a  CFAR  detection  technique  with  the  threshold  normalized  ot  the  average  value. 
The  maximum  peak-to- average  ratio,  denoted  as  Range-Var,  is  used  to  discriminate 
between  CW  and  other  types  of  jammer. 

The  rule  to  determine  the  jammer  type  is: 


IF 


1.0  <•  Ranga-Var  <-  2.0 
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THEN 

Janaer  is  CV  type. 

Go  to  Identify  CU  Jammer. 

ELSE 

Jammer  is  non-cv  type. 

Go  to  Identify  Non-CW  Jammer. 


Note:  limit  values  were  determined  by  experimentation. 


1.3. 2. 3  Identify  CW  Jammer  The  discriminant  Freq.Vat,  calculated  for  the 
first  PRI  of  the  passive  dwell,  is  used  to  distinguish  wideband  and  narrowband  jam¬ 
mers.  The  discriminant  SidelobeJDuty factor  is  used  to  distinguish  mainlobe  and 
sidelobe  jammers.  Passive.Var  is  also  calculated  for  the  first  PRI  and  can  be  used  in 
future  upgrades  to  distinguish  multiple  jammers  in  a  beam. 

Freq-Var  is  computed  by  finding  the  peak  and  the  average  value  of  the  Pas- 
siveJJwell-PVeqJPower  vector  for  the  PRI  chosen  and  dividing  the  peak  by  the  average 
to  get  the  Freq_Var. 

Passive- Var  is  computed  as  follows.  Using  the  PRI  chosen,  compute  the  mean  of  tl' 
elements  of  the  Passive_Dwell-Range_Var  (the  sum  of  the  PassiveJDwell_Range_'  ’ 
vided  by  Samples-Per-PRI).  Divide  it  by  the  mean  of  the  Passive_Dwell_Rangc  ' 
(the  sum  of  Passive-Dwell-Range-Power  divided  by  Samples-Per-PRI)  squa^  .. 


Passive- Var  = 


j^Max-Range-Cells  passive-Dwell-Range_Var[i] 
^  SampIes-per-P  RI 


( 


y^Ma?:-Rar'ge-Cell8  Passive-DwelLRange-Powerit 
Samples-per-Plll 


■y 


Sidelobe-Duty_Factor  is  computed  by  comparing  £dl  eight  Sidelobe-Sum  and  finding 
the  one  that  occurs  most  frequently,  within  4-  or  -  5  counts.  This  count  is  then  divided 
by  the  total  samples  per  PRI  (which  equals  3000  for  this  implementation). 

Using  the  results  of  the  preceding  calculations,  the  rules  to  identify  CW  jammers  are: 


IF 


1.0  <»  Freq.VaLr  <■  3.0  AND 
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0.0  <■  Sideiobe_Duty..Factor  <■  0.10 
THEN 

Daclare  wideband  cw  mainlobe  jeisuner. 


IF 

1.0  <■  Freq_Var  <*3.0  AND 

0.10  <■  Sidolobe_Duty .Factor  <■  1.00 

THEN 

Declare  videbemd  cw  sidelobe  janiner. 


IF 

Freq.Var  >  3.0  AND 

0.0  <“  Sidelobe.Duty.Factor  <*  0.10 

THEN 

Declare  narrowband  cw  mainlobe  jammer. 


IF 

Freq.Var  >  3.0  AND 

0.10  <■  Sidelobe.Duty .Factor  <=  1.00 

THEN 

Declare  narrowband  cw  sidelobe  jammer. 

1.3. 2. 4  Identify  Non-CW  Jammers  At  this  point,  a  jammer  has  been  detected 
which  is  not  CW.  Since  a  given  PRI  may  not  contain  the  jammer  pulse  due  to  the 
asynchronous  nature  of  the  jammer,  the  software  needs  to  determine  which  PRI  data 
to  use.  To  do  this,  the  Mainlobe_Duty_Factor  is  calculated  for  each  PRI  of  the 
Passive-Dwell-RangeJPower  vector. 

For  each  PRI  where  the  peaJc-to-average  ratio  exceeds  2.0,  set  the  range  thresh¬ 
old  half  way  between  the  peak  and  average  value  of  the  Passive_DwelLRsnge.  Power 
vector.  Using  this  threshold,  count  the  number  of  threshold  crossings  in  the  Par- 
si  ve_Dwell_RangeJPower  vector  for  that  PRI.  Divide  this  count  by  Max  .Range-Cells 
to  obtain  the  duty  factor.  The  PRI  with  the  largest  ratio  is  the  PRI  used  for  other 
determinate  calculations.  The  ratio  is  denoted  an  the  Mainlobe JDufcyJFactor.  If  mul- 
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tiple  PRIs  have  the  same  duty  factor,  the  PRI  with  the  pulse  closest  to  the  center  of 
the  range  vector  is  chosen.  This  PRI  is  then  used  to  calculate  the  Freq.Var  and  the 
Passive_Var  discriminants  as  above.  The  SidelobeJL)uty_Factor  will  also  be  used  and 
is  calculated  as  in  Section  1. 3. 2.3. 

The  rules  for  identifying  non-CW  jammers  are  as  follows: 


0.01  <»  Mainlobtt.Duty.Factor  <■  0.10  AND 

1.0  <»=  Freq_Var  <*3.0  AND 

0.0  <■  Sidelobe_Duty_Factor  <■  0.01 


THEN 

Declare  wideband  asynchronous  pulse  mainlobe  jarniser. 


IF 

0.01  <*  Mainlobe.Duty_Factor  <*  0.10  AND 

1.0  <-  Freq.Var  <*3.0  AND 

0.01  <  Sidelobe.Duty.Factor  <■  0.15 

THEN 

Decleire  wideband  asynchronous  pulse  sidelobe  jammer. 


IF 

0.01  <=  Mainlobe_Duty_Factor  <*  0.10  AND 

Freq.Var  >  3.0  AND 

0,0  <*  ,Sidelobe_Duty_Factor  <»  0.01 

THEN 

Declai'e  narrowband  asynchronous  pulse  mainlobe  jammer. 


IF 

0.01  <*  Mc.inlobe_Daty„Factor  <»  0.10  AND 

Freq.Vax  >  3.0  AND 

0.01  <  Sidelobe_Di-  y_Factor  <*  0.15 

THEN 

Declare  narrowband  asynchronous  pulse  sidelobe  jammer. 
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IF 

1.0  <■  Freq_Var  <-3.0 
THEN 

Declare  wideband  unknown  jammer. 


IF 

Freq_Var  >3.0 
THEN 

Declare  narrowband  unknown  jeuamer. 


Notice  the  redundancy  in  several  of  the  rules.  In  particular,  the  last  two  rules  ensure 
that  even  if  a  jammer  is  unable  to  be  discriminated  as  CW  or  asynchronous  pulsed, 
it  will  still  be  identified  as  wide  or  narrowband  and  the  appropriate  ECCM  may  be 
applied.  Because  of  the  Prolog  inferencing  order,  the  most  informative  identification 
possible  will  be  made. 

1.3.3  Outputs 

When  a  match  v/ith  one  of  the  jammer  rules  is  found,  the  declared  jammer  is  asserted 
into  the  Prolog  database  along  with  the  applicable  parameters;  Peak_JNR,  Jam¬ 
mer-Range,  and  MainlobeJDutyJFactor.  These  parameters  are  calculated  over  the 
same  PRI  used  to  make  the  discriminant  calculations.  The  Peak-JNR  is  computed 
by  finding  the  largest  Passive_Dwell_Range_Power  element  and  then  divided  by  the 
product  of  the  number  of  samples  per  range  cell  and  the  square  of  Sigma_Q.  The  Jam¬ 
mer-Range  is  the  range  bin  where  the  Peak-JNR  is  found.  The  Mainlobe-Duty-Factor 
has  adready  been  calculated  for  pulsed  jammers.  For  CW  jammers  it  is  set  to  1.0. 
The  facts  take  the  following  form; 

jasuner.foundC  Beaim.Cnt,  Type,  Lobe,  BW,  Peak.JNR, 

Jammer .Range,  Hainlobe.Duty.Factor  ). 


where 

•  Beam-Cnt  is  the  beam  number  in  which  the  jammer  is  present. 
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•  Type  is  cw  (noise),  asp  (async-pulsed),  or  unknown. 

•  Lobe  is  ml  (mainlobe),  si  (sidelobe),  or  unknown. 

•  BW  is  nb  (narrowband)  or  wb  (wideband). 

•  Peak-Range  Jf  NR  is  the  peak  jammer- to-noise  ratio. 

•  Jammer-Range  is  the  range  bin  where  the  PeakJlange.JNR  was  found. 

•  MainlobeJDuty-Factor  is  the  ratio  of  the  number  of  threshold  crossings  in  the 
Passive-Range  vector  to  the  number  of  range  bins.  For  CW  jammers  this  value 
is  set  to  1.0. 

1.3.4  Upgrade  Options 

Among  the  parameters  that  are  computed,  but  not  yet  used  in  the  rules  is  a  Pas¬ 
sive-Variability.  This,  in  conjunctiai  with  the  other  parameters,  will  be  used  to  detect 
multiple  jammers  in  a  single  beam. 

The  current  rules  assume  that  a  jammer  is  identified  or  not,  with  no  provision  for 
uncertainty.  A  next  iteration  of  rules  should  associate  a  probability  or  certainty  factor 
with  each  identification. 

1.4  ID  Active  Interference  Rulebase 

ID  Active  Interference  takes  2is  input  a  set  of  discriminant  values,  which  are  canputed 
for  every  beam,  and  a  clutter  identification  rulebase.  The  function  uses  the  current 
beam  discriminants  and  searches  the  rulebase  for  a  match.  If  a  match  is  found,  it 
declares  the  appropriate  clutter,  and  computes  the  appropriate  parameters.  If  no 
match  is  found  then  it  declares  that  no  clutter  has  been  found. 

1.4.1  Inputs 

The  components  of  Beam  Scan  Data  that  are  used  in  ID  Active  Interference  are: 

•  Active-DwellJPower:  an  array  whose  components  contain  the  results  of  a 
doppler  filter  bank  computed  over  the  16  PRIs  of  the  active  listening  dwell, 

•  ActiveJDwell-Var;  an  array  whose  componenents  contain  the  square  of  the 
doppler  filter  bank  compu.»  d  over  the  16  PRIs  of  the  active  listening  dwell. 

The  Clutter-Map  and  Weather-Map  records  from  the  Radar  Environment  parameters 
are  used. 
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The  following  parameters  calculated  at  system  initialization  are  used: 

•  Norm-Const 

•  Active-DwelLThreshold 


1.4.2  ID  Active  Interference  Preprocessing 

The  following  are  calculated  to  be  used  as  discriininants  in  the  ID  Active  Interference 
rulebase. 

Active- Variability:  Compute  the  sum  of  the  elements  of  the  ActiveJDwell-Var  and 
divide  it  by  the  sum  of  the  elements  of  the  Active-Dwell-Power  squared,  as  follows, 
to  form  the  Active-Variability: 


ActiveJVariability 


^Max-Range-Cells  ^Max-Doppler-CeUs  Active-Dweli-Var[..i] 
(Max-Doppler-Cells*Max-Range-Cells) 
^Max-Range-Cells  ^Max-Doppler-Cells  Active-Dwell-Power[.,j] 
(Max-Doppler_Cells*Max-Range-Cells) 


Clutter  Map  Parameters:  Four  discriminants  calculated  using  the  Radar  En¬ 
vironment  Parameter,  Clutter-Map.  They  are  Ground-Power,  Ground-Var, 
In-Ground-Match,  and  Out-Ground-Match. 

Ground-Power;  Sum  the  Active-Dwell-Power  array  of  the  true  locations  in  the  Clut¬ 
ter-Map. 

Ground-Var:  To  compute  this  relative  to  the  Clutter-Map,  do  the  following: 

1.  For  each  element  in  Active_Dwell_Power  which  exceeds  the  threshold,  Ac- 
tive-Dwell-Threshold,  normalize  by 

_1_ 

R} 

where  i  is  the  range  index  of  the  element  minus  one. 

2.  Normalize  the  corresponding  elements  in  Active_Dwell_Var  by 


1 

Rt 


134 


3.  Compute  Ground.Var  as  is  done  to  calculate  the  Active-Variability  above,  using 
the  normalized  elements  from  above  and  dividing  by  the  number  of  threshold 
crossings. 

In_Ground_Match:  Threshold  the  Active_DwellJ’owei  array  and  finding  the  number 
of  trues  that  correspond  to  the  trues  of  the  Clutter_Map  and  then  divide  by  the  total 
number  of  trues  in  the  Clutter_Map. 

Out-Ground-Match:  Using  the  thresholded  Active-Dwell-power  array  from  above, 
and  find  the  number  of  falses  that  match  the  falses  of  the  Clutter-Map  and  divide  by 
the  total  number  of  falses  in  the  Clutter-Map. 

Weather  Map  Parameters  Four  discriminants  are  calculated  using  the  Radar 
Environment  parameter,  Weather-Map.  They  are  WeatherJPower,  Weather-Var, 
In-Weather_Match  and  Out-Weather-Match.  They  are  calculated  similarly  to  the 
corresponding  Clutter  Map  parameters  by  substituting  the  Weather-Map  for  the  Clut¬ 
ter-Map. 

1.4.3  Rules 

The  following  rules  are  used  to  detect  ground  and/or  weather  chitter: 


IF 

Ground.Pover  is  lov  AND 
Weather.Power  is  lov 

THEN 

Exit  ID  Active  Interference  subproblem 


Ground.Power  is  high  AND 
In_Ground_Match  is  high  AND 
Heather-Power  is  high  AND 
In-Weathe7r_Match  is  high 

THEN 

declare  Weather  Clutter  AND 
declare  Ground  Clutter 
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Ground.Pcver  is  high  AND 
In_Groiind_Match  is  high 


THEN 

declare  Ground.Clutter 


Weather.Pouer  is  high  AND 
In_Heather_Match  is  high 


THEN 

declare  Weather_Clutter 


1.4.4  Output 

If  Ground  Clutter  is  present,  compute  the  Peak  CNR,  Maxrange_Ground  and  the 
Ground-CNR-Maxxange  of  the  cells  over  which  the  ground  clutter  map  falls. 

If  Weather  clutter  is  present,  compute  the  Peak  CNR,  Min_DopplerJndex, 
MajcJDoppler .Index,  Maxrange_Weather,  and  Wealher.CNR-Maxrange  of  the  cells 
over  which  the  weather  clutter  map  falls. 

Peak  CNR  is  computed  by  finding  the  maximum  Activ.;J)wellJ*ower  entry  which  falls 
within  the  clutter  map  of  interest.  The  corresponding  Active-DwelLVar  element  is 
then  divided  by  the  product  of  the  number  of  samples  per  cell,  the  square  of  Sigma-Q, 
and  MaxJ)oppler_Cells. 

Min JDopplerJndex-WX  and  MaxJDoppler Jindex_WX  are  computed  a.8  follows; 

1.  Tramslate  the  doppler  indices  in  the  following  manner: 

if  Doppler-Cnt  >  9  then  Doppler_Index  =  Doppler _Cnt  -  17 
else  DoppIerJndex  =  Doppler-Cnt  *  1 

2.  Find  the  minimum  Doppler.Index  where  a  threshold  crossing  exists  in  the  Ac- 
tive-DweU-Power  and  denote  eis  Min_DopplerJndex_WX. 

3.  Find  the  maximum  Doppler_Index  where  a  threshold  crossing  exists  in  the  Ac- 
tive.J)wellJPower  and  denote  as  Max_Doppler_Index_WX. 

To  calculate  Maxrange  and  CNR_Maxr.ange,  find  the  maximum  range  at  which  a 
threshold  crossing  occurs  with  respect  to  the  appropriate  map  and  designate  it  as  the 
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Maxrange.  Then  find  the  largest  element  in  this  range  bin  in  the  Active-DwelLPower 
array,  with  respect  to  the  appropriate  map.  Take  the  corresponding  element  of  the 
Active_Dwell_Var  array  and  divide  it  by  the  product  of  the  number  of  samples  per 
range  cell,  square  of  Sigma,.Q,  and.  Max_Doppler_Cells  and  denote  as  CNR_Maxrange. 

When  a  match  is  found,  report  the  existence  of  the  declared  interference  by  asserting 
the  appropriate  fact  into  the  Prolog  data  base  as  shown  below: 

ground_clutter(  Beain_Ciit,  Ground„Peak_CNR,  Ground_CNR_Maxrange , 
MsLzrange.Ground  ) . 


where 

•  Beam-Cnt  is  the  beam  number  in  which  the  ground  clutter  is  found. 

•  GroundJPeak-CNR  is  the  peak  clutter-to-noise  ratio. 

•  Ground-CNR,  Maxrange  is  the  peak  CNR  at  the  maximum  range  of  the  ground. 

•  Maxrange..G\  Aind  is  the  largest  range  index  at  which  ground  interference  is 
found. 

and 


weatherC  Beam_Cnt,  Weatbier„Peak_CNR,  Min_Doppler_Wx,,  Max_Doppler_Wx, 
Wfeather„CNR„Maxrange,  Maxrange.Weather  ) 


where 

•  Beam-Cnt  is  the  beam  number  in  which  weather  is  found. 

•  Weather_Peak_CNR  is  the  peak  clutter-to-noise  ratio  of  the  weather. 

•  Min-Doppler_Wx  is  the  normalized  minimum  doppler  extent  of  the  weather. 

•  MaocJDoppler.Wx  is  the  normalized  maximum  doppler  extent  of  the  weather. 

•  Weather-CNR-Maxrange  is  the  peak  CNR  at  the  maximum  range  of  the  weather 
interference. 

•  Maxrange. Weather  is  the  largest  range  index  at  which  weather  interference  is 
found . 
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1.4.5  Upgrade  Options 

The  current  rules  have  no  provision  for  uncertainty.  A  next  iteration  of  rules  should 
associate  a  probability  or  certainty  factor  with  each  identification. 

Presently,  no  responsive  jammers  are  detected.  Rules  could  be  added  to  enable  de¬ 
tection  of  these  types  of  jammers. 


1.5  Determine  Applicable  ECCM 

Determine  Applicable  ECCM  is  a  procedural  subproblem  whose  inputs  are  the  detec¬ 
tions  and  parameters  asserted  into  the  Prolog  database  by  the  ID  Passive  Interference 
and  ID  Active  Interference  subproblems  and  whose  outputs  are  a  schedule  for  ECCM 
allocated  to  the  beams  in  the  next  scan. 

1.5.1  Inputs 
Inputs  include: 

•  Jammer-found  facts  from  the  ID  Passive  Interference  subproblem. 

•  Ground  clutter  and  weather  facts  from  ID  Active  Interference  subproblem. 

•  Various  Radar  Design  Pareuneters  used  to  modify  signal-to-noise  ratios  and 
target  losses. 

1.5.2  Processing 

Processing  is  on  a  beam-by-beam  basis.  The  following  Radar  Control  Parameters  are 
initialized  to  default  parameters  as  specified  at  system  initialization: 

•  ECCMS  on 

•  Pulse  Duration 

•  Pulse  Bandwidth 

•  Transmit  Polarization 

•  Receive  Polarization 

•  Adaptive  MTI  Weights 

•  Dwell  Time  Per  Look 

•  Number  of  Looks 
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Transmit_Center_Freq  is  initialized  to  the  last  value  used  rather  than  the  value  at 
system  initialization. 

1.5. 2.1  Jammer  ECCM  The  following  jammer  ECCM  will  be  enabled  as  allowed 
by  Radar  Design  Parameters  and  AI  Control  Parameters. 

Frequency  hopping  is  enabled  if  the  beam  contains  a  narrowband  jammer.  When 
frequency  hopping  is  performed,  the  peak  jammer-to-noise  ratio  of  the  jammer  is 
decreased  by  the  Freq-SidelobeXevel  Radar  Design  Parameter. 

The  sidelobe  canceller  is  enabled  if  the  beam  cxsntains  a  CW  sidelobe  jammer  with 
a  corresponding  decrease  in  the  jammer-to-noise  ratio  by  the  signal- to- jammer  im¬ 
provement. 

The  sidelobe  blanker  is  turned  on  if  the  beam  contains  an  asynchronous  pulsed 
sidelobe  jammer.  The  peak  jammer-to-noise  ratio  of  each  such  jammer  is  set  to  zero. 

The  composite  wideband  januner-to-noise  ratio  is  calculated  by  adding  the  square  of 
the  peak  JNRs  for  each  wideband  jammer  in  the  beam  and  then  taking  the  square 
root  of  the  sum. 

The  composite  narrowband  JNR  is  calculated  by  adding  the  sqviare  of  the  peak  JNRs 
for  each  narrowband  jammer  in  the  beam  and  then  taking  the  square  root  of  the  sum. 

1.5. 2. 2  Clutter  ECCM  K  polarization  is  allowed  and  weather  is  present,  the 
transmit  polarization  is  changed  from  Horizontal  to  Vertical.  The  Peak_CNR  and 
the  CNR_Maxrange  are  decreased  by  the  PolarizatiomRain-Gain.  The  Target_Loss 
(which  is  initially  onsy  is  increased  by  the  Polarization-TargetXoss. 

An  MTI  weight  set  is  chosen  so  as  to  notch  any  weather  and/or  ground  clutter 
spread.  The  Peak_CNR  and  CNRJVIaxrange  of  the  veather  and/or  ground  are  then 
decreased  by  the  Clutter- to- Noise  Improvement.  The  TargetXoss  is  increased  by  the 
MTIXoss. 


1.5. 2. 3  Dwell  Time  Calculation.s  The  Per_Pulpe_SNR  is  divided  by  the  target 
loss  and  then  multiplied  by  the  Pulse JDuration  and  the  Radax_Instant_BW.  Using  this 
adjusted  Per_Pulse.SNR,  the  signal-to-clutter  ratios  are  calculated  for  any  weather 
or  ground  clutter  still  present.  Ss  al-to-jammer  ratios  are  calculated  using  the  com¬ 
posite  JNR_NB  and  JNR_WB. 

Dwell  time  per  look  is  calculated  by  multiplying  the  number  of  MTI  pulses  by  the 
PRI  used. 

The  number  of  looks  required  to  maintain  probabilities  of  detection  .1  through  .9  is 
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calculated  for  each  beam.  This  is  done  by  finding  the  number  of  looks  to  compensate 
for  each  interference  type  found  as  well  as  the  number  of  looks  to  compensate  for 
noise.  The  maximum  number  of  looks  is  then  used. 


1.5.3  Outputs 

A  table  of  radar  controls  is  output  with  each  column  representing  increasing  proba¬ 
bility  of  detection.  This  Pascal  array  consists  of  the  following  records; 

•  Trajis-Center-Freq 

•  Sidelobe-Blanking-On 

•  Sidelobe-Cancelling_On 

•  CFAR 

•  PRI 

•  PulseJ)uration 

•  PulseJBandwidth 

•  Tx«Polarization 

•  RxJ’olaxization 

•  Adaptive-MTLWeights 

•  Dwell_Time_per_Look 

•  Number-of-Looks 

1.5.4  Upgrade  Options 

Presently  several  of  the  control  parameters  are  not  used  to  counteract  interference. 
In  the  future  new  rules  could  be  added  utilizing  these  ECCMs  and  radar  controls. 

1.6  Allocate  Radar  Resources 

Allocate  Radar  Resources  is  a  procedural  subproblem  whose  inputs  are  the  outputs 
from  the  Determine. App!icable_EC CM  subproblem  as  well  as  the  Priority  Zones, 
Quality  Option  plans  and  desired  scan  time,  and  whose  outputs  are  the  Radar  Control 
parameters  to  be  used  for  the  next  scan. 


140 


1.6.1  Inputs 

The  inputs  to  this  subproblem  include  the  table  of  BLadar  Control  Parameters  pro¬ 
duced  by  the  Determine  Applicable  ECCM  subproblem,  the  Priority  Zone  Parameters 
and  the  Quality  Option  Plan.  These  data  structures  are  discussed  in  detail  in  previous 
sections  and  the  appropriate  appendices. 

1.6.2  Processing 

As  part  of  AI  Control  Parameters  and  Priority  Zone  Parameters,  the  user  has  input  a 
desired  scan  time  and  has  assigned  priorities  to  the  different  regions  of  scan  coverage. 
The  Quality  Option  Plan  assigns  a  desired  probabilty  of  detection  to  each  Priority 
Zone  in  a  set  of  decreasingly  costly  plans. 

The  total  scan  time  required  to  achieve  the  probabilities  of  detection  assigned  to  the 
different  priority  zones  under  each  Quality  Option  is  computed,  starting  with  the  first 
quality  level  until  a  plan  is  reached  that  does  not  exceed  the  desired  scan  time.  This 
is  done  by  adding  together  for  each  beam  interbeani  dead  time,  total  dwell  time  for 
CPI3  as  calculated  using  the  appropriate  probability  of  detection,  CPU  dwell  time  if 
it  is  to  be  performed  and  CPI2  dwell  time  if  it  is  to  be  performed. 

Once  a  quality  option  plan  has  been  found,  any  remaining  dwell  time  is  allocated 
across  all  beams  in  order  to  maximize  use  of  the  desired  scan  time. 

If  the  desired  scan  time  is  exceded  for  each  Quality  Option  in  the  schedule,  a  default 
option  assigns  the  total  available  scan  time  to  the  zones  with  highest  priority  so  as 
to  achieve  equal  probability  of  detection  in  each. 

1.6.3  Outputs 

The  output  will  be  the  Scan_Radar_Control  array  which  contains  Radar  Control  Pa¬ 
rameters  for  each  beam  in  the  next  scan. 
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1.7  Rulebase  Evolution 

Rulebase  developmeDt  is  an  iterative  process  of  formulating  rules  and  evaluating  their 
impact.  The  well-designed  experiment  will,  therefore,  provide  a  framework  within 
which  rules  can  evolve. 

The  IMRD  differs  from  other  expert  systems  work  in  that  its  expertise  is  a  combi¬ 
nation  of  existing  human  knowledge  (available  at  the  beginning  cf  the  contract)  and 
detailed  knowledge  of  how  the  system  behaves  (available  as  the  contract  progressed). 
Thus,  rulebase  flexibility  was  critical  tc  successful  development, 

Both  the  initial  hardware/software  design  and  the  adaptive  control  software  sup¬ 
ported  iterative  development  well  and  enabled  us  to  model  adaptive  control  experti.'^e 
successfully.  The  following  sections  summaurize  our  observations  and  findings  during 
this  process. 

1.7.1  ID  Passive  Interference 

A  number  of  findings  during  ID  Passive  Interference  development  influenced  the  final 
rulebase.  Among  the  areas  that  required  moaificAtion  were  the  following: 

Changes  in  Beam  Scan  Data  inputs:  Origii:ally,  we  calculated  the  outputs  of 
doppler  filter  banks  over  16  PRIs  of  passive  dwell  and  16  PRIs  of  active  dwell.  This 
is  appropriate  for  the  active  dwell,  but  was  modified  for  the  passive  dwell  to  better 
reflect  how  interference  appears  in  the  passive  dwell  data.  We  had  a.ssumed  that 
pulsed  jammers  would  show  up  as  threshold  crossings  at  epecific  time  Dins ,  whereas 
CW  noise  jammers  would  be  spread  across  all  time  bins.  However,  pulse  jammers  are 
asynchronous  to  the  received  PRI  and,  therefore,  are  spread  across  the  dcppler  filtei' 
map.  This  was  accounted  for  by  performing  an  FFT  on  each  of  the  first  eight  PRIs 
and  producing  eight  separate  frequency  and  range  vectors  T.  he  number  of  PRIs  used 
in  the  ID  Passive  Interference  subprcblem  was  varied  during  testing.  We  determined 
that  using  eight  gave  good  performance  against  asynchronous  jammers  with  a  very 
small  probability  of  eclipsing  in  all  PRIs. 

Musing  ASP  jammers:  Even  with  the  enhancements  described  above,  ASP  jammers 
were  not  always  detected.  This  was  ascribed  to  several  factors:  1)  the  jammer  might 
not  be  transmitting  during  the  single  PRI  from  which  data  was  collected,  2)  a  small 
region  of  the  range  vector  is  gated  out  by  the  equipment,  and  3)  we  process  only  the 
first  900  samples  of  a  given  PRI. 

To  lessen  the  chance  of  missing  an  ASP  jammer  because  it  does  not  appear  in  the 
single  PRI,  the  duty  factor  was  calculated  based  on  the  threshold  crossings  for  e^w:h 
PRI.  The  Pill  containing  the  largest  duty  factor  was  then  used  to  calculate  the  fre- 
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quency  variability,  as  previously  described.  When  we  tested  this  new  discriminant 
calculation,  we  started  to  get  false  CW  declarations  when  expecting  pulsed.  This  oc¬ 
curred  more  frequently  when  we  were  looking  at  a  mainlobe  jammer.  After  analyzing 
the  data,  we  concluded  that  the  pulse  jammer  had  a  CW  noise  component  which  was 
raising  the  base  thermal  noise  level.  Therefore,  a  duty  factor  based  on  a  fixed  thresh- 
olded  thermal  noise  would  incorrectly  produce  a  duty  factor  of  close  to  one,  unless 
the  threshold  is  signihcantly  raised  with  a  corresponding  decrease  in  sensitivity. 

Wideband/narrowband  discrimination:  The  first  wideband/narrowband  discrimi¬ 
nant  tested  we;s  Percent_Passive_Frequency_Crossings  (the  percent  of  cells  in  the  pas¬ 
sive  frequency  vector  which  exceed  the  passive  frequency  threshold)  in  a  single  PRI. 
The  threshold  was  calculated  by  multiplying  the  passive  frequency  thermal  noise  vec¬ 
tor  by  a  constant  and  was  set  high  by  necessity  to  discriminate  narrowband  and 
wideband  jammers  . 

Narrowband  and  wideband  jammers  were  not  always  correctly  discriminated  by  the 
Percent  JPassive_Frequency_Crossings  when  the  jammers  were  in  the  antenna  sidelobes 
because  of  the  high  threshold  setting  and  the  low  received  jammer  power:  when 
the  passive  frequency  threshold  v.-as  set  low,  narrowband  jammers  were  erroneously 
identified  as  wideband. 

A  more  useful  observation  was  that  narr-iwband  jammers  had  large  differences  in 
value  over  the  different  frequencies,  whereas  the  wideband  jammers  had  more  nearly 
consistent  values  over  all  frequencies. 

Frequency  Variability-the  peak  frequency  value  divided  by  the  average  frequency 
vaJue-is  now  used  to  discriin/njte  butweei.  wideband  and  narrowband  jamming,  with 
wideband  having  the  lower  valuesThus,  large  relative  differences  in  amplitude  which 
may  occur  over  only  a  small  per<;entage  of  the  frequency — rather  than  the  percentage 
of  the  frequency  spectrum  in  which  the  power  level  exceeds  an  absolute  threshold — 
indicate  narrowbsmd  jamming. 

A.SP/CW  discrimination:  An  early  version  of  the  rules  thresholded  the  Pcis- 
sive-DwelUreq-Power  for  aJl  eight  PRIs.calcuJated  the  duty  factor  for  each,  and 
chose  the  PRI  with  the  highest  duty  factor  for  further  calculations.  We  found  that 
pulsed  mainirl'e  jammers  leaked  continuous  noise  energy  that  exceeded  the  fixed 
threshold  and  caused  ASP  jammers  to  be  lde:.tified  as  CW  jammers.  Analysis  of  the 
data  indicated  that  a  peak-to-average  ratio,  denoted  Range. Var,  of  the  range  vector 
could  be  used  to  distinguish  between  a  CW  and  a  pulsed  jammer.  However,  we  now 
needed  a  new  discriminant  to  determine  if  any  jammers  were  present  before  preceding 
with  any  further  jammer  identification.  A  Range_Crossing.s_Ratio  was  calculatec  by 
taking  the  number  of  passive  range  vector  threshold  crossings  in  eight  PRIs,  usiug 
the  passive  range  thermal  noise  vector  multiplied  by  a  constant  as  the  threshold,  and 
dividing  by  the  total  number  of  threshold  cells  in  all  eight  PRIs.  If  this  value  is  larger 
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than  zero,  some  kind  of  jammer  is  present  and  jamriier  idefiiihcat-nn  can  continue. 

The  Mainlobe  Duty  Factor  was  designed  to  discriminate  between  CW  and  ASP  jam 
mers  with  CW  jammers  having  a  high  value  and  ASP  a  icvv  value.  The  rationale 
was  that  a  jammer  with  more  range  crossings  during  the  passive  listening  interval 
operated  over  a  larger  time  frame  and  would  be  CW,  whereas  a  pulstxl  jammer  would 
appear  in  only  a  few  cells. 

Modifications  to  accommodate  errors  in  sidetobe  couiit:  The  sidelobe  count  is 
occasionally  placed  incorrectly  in  the  header,  ^;a using  inccrreci  identification  of  main- 
lobe  and  sidelobo  jammers.  To  compensate  for  this,  we  compar'^  sidelobe  counts  for 
all  eight  PRIs  and  choose  the  count  which  occurs  most  frequently  within  +5  counts. 
This  count  allows  correct  discrimination  between  mainlobe  and  sidelobe  jammers. 

1.7.2  ID  Active  Interference 

Clutter  maps  versus  clustering  algorithms:  Original  rules  used  discriminants  bared 
on  calculating  the  size  and  power  of  clusters  of  threshold  acssings  in  the  active  dv/ell 
Beam  Scan  Data.  Sin<x;  these  calculations  required  a  lot  of  CPU  time  as  well  as  being 
difficult  to  modify  and  expand,  we  used  the  different  approach  of  predcteiirJnod 
boolean  maps  to  indicate  elements  in  the  active  dwell  power  array  at  which  threshold 
crossings  for  a  given  type  <,f  interference  are  expected. 

Ground  clutter  and  DC  offset  in  weather  data:  Initially,  we  used  only  the  power 
determinate  calculated  over  both  the  ground  and  the  weather  maps.  The  ground 
clutter  map  had  trues  in  the  zero  doppler  bin  out  to  the  seventh  integrated  range  cell. 
The  weather  map  was  the  inverse  of  the  ground  map.  A  high  ground  power  indicated 
ground  clutter  and  a  high  weather  power  indicated  weather. 

One  observation  was  that  ground  clutter  tended  to  spread  into  all  doppler  at  close  in 
ranges  due  to  higher-than-expected  equipment  doppler  sidelobe  levels.  This  caused 
these  returns  \,o  overwhelm  weather  returns.  The  first  two  range  cells  of  the  predefined 
weather  map  were  blanked  to  elimiiate  ground  returns;  the  zero  and  two  adjoining 
doppler  bins  were  notched  out  to  exci.se  DC  offset;  and  additional  determinste  tests 
were  added. 

A  test  for  In_Ground_Matcb  imd  Iii_Weatber..AIatch  were  added  to  eliminate  false 
alarms.  In  order  to  declare  ground  clutter,  the  In-Ground-Match  had  to  be  above  a 
certain  percentage,  as  did  weather  clutter. 

Low  fail-rate  versus  distributed  weather:  The  rulebase  did  not  initially  detect 
cellular  weather  that  appears  in  only  a  few  range-doppler  ceils.  This  was  due  in 
part  to  a  collapsing  loss  effect  of  integrating  over  many  more  cells  than  that  which 
encompasses  the  weather  return.  This  was  alleviated  by  lowering  the  thresholds  and 
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J  I?vlRD  Test  Cases 

This  appendix  describes  the  tests  that  were  performed  during  the  IMRD  final  pre¬ 
sentation.  The  test  cases  and  expected  results  are  summarized  in  Table  12  contained 
in  Section  4.2. 

J.l  Test  0:  Benign  Environment 

The  purpose  of  this  test  is  to  initialize  the  IMRD  system  and  witness  baseline  per¬ 
formance  under  conditions  of  no  interference.  The  remaining  tests  assume  the  same 
conditions  unless  noted. 

J.1.1  Procedure 

1.  Perform  software  initialization  procedures  as  specified  in  the  User  Manual,  Sec¬ 
tion  3.1. 

2.  Set  autenna  elevation  to  -f  6  degrees. 

3.  Start  the  Adaptive  Controller  on  the  VAX  terminal  and  specify  the  default 
inputs. 

4.  Start  the  software  on  the  HP  terminal.  Set  the  antenna  azimuth  to  95  degrees. 

5.  To  terminate  this  test  type  any  key.  This  will  return  control  to  the  User  Interface 
at  the  end  of  the  current  scan. 

6.  Note  the  following: 

(a)  the  contents  of  the  PPI  display 

(b)  sources  of  interference  indicated  on  the  AI  display. 


J.l. 2  Expected  Results 

No  interference  should  be  identified  for  any  of  the  beams.  A  sample  AI  display  line 
will  be  similar  to  the  following: 

Beam  Dwell  Time  Interferences  ECCMs  Changed 

per  Beam  Found 

1  0.054 
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The  simulated  uncompressed  target  will  be  present  at  range  5  miles. 

When  the  user  types  a  key  at  the  VAX  terminal,  the  Adaptive  Controller  Options 
Menu,  as  described  in  User  Manual,  Section  3.2.1,  will  appear  at  the  end  of  the  next 
scan. 


—  OPTIONS  MENU  — 


Select  em  option  by  entering  one  of  the  numbers: 


0  -  Continue 

1  “  AI  Control  Parameters 

2  -  Priority  Zone 

3  -  Quality  Options 

4  -  AI  Outputs 

5  -  Quit 


Continue  program  execution. 

Change  AI  control  facts. 

Change  Priority  Zone  Definitions. 
Cheinge  Quality  Options  Table. 
Change  amount  of  interscem  output . 
Quit  the  IMRD  program. 


Please  enter  n\unber  of  menu  selection.  -> 

At  this  time,  the  user  can  change  items  in  any  of  the  listed  categories. 


J.2  Test  1;  Ground  Clutter 

The  purpose  of  this  test  is  to  verify  that  the  IMRD  software  is  capable  of  identifying 
ground  clutter  and  applying  appropriate  adaptive  control,  MTI  weights. 

J.2.1  Procedure 

1.  Set  antenna  elevation  to  +.3  degrees. 

2.  Use  the  Adaptive  Controller  Options  Menu  to  set  the  ai^n  parameter  to  “no”, 
display 

3.  Continue  the  Adaptive  Controller,  observing  the  PPI  and  AI  displays. 

4.  Use  the  Adaptive  Controller  Options  Menu  to  set  the  aijon  parameter  to  “yes” . 

5.  Terminate  the  test  by  striking  any  key. 

6.  Note  the  following: 

(a)  the  contents  of  the  PPI  display 

(b)  sources  of  interference  indicated  on  the  AI  display 

(c)  AI  decisions  indicated  on  the  AI  display. 
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J.2.2  Expected  Results 

During  the  scans  with  ai.on  set  to  “no”,  ground  clutter  will  appear  in  selected  beams 
on  the  UPA-62  PPL  Targets  (simulated  and  targets  of  opportunity)  will  be  masked  by 
ground  clutter.  The  AI  display  will  indicate  that  ground  clutter  has  been  detected  in 
some  or  all  of  the  beams,  but  that  no  adaptive  control  actions  will  be  taken.  Sample 
display  lines  are  shown  below. 

Beam  Dvell  Time  Interferences  ECCMs  Chemged 

per  Beam  Found 

1  0 . 054  ground 

During  the  first  scan  with  ai-on  set  to  “yes”,  ground  clutter  will  appear  on  the  UPA- 
62  PPL  The  AI  display  will  indicate  that  ground  clutter  has  been  detected,  and 
that  MTI  will  be  used  to  counteract  the  ground  in  those  beams  where  it  is  detected. 
Sample  display  lines  are  shown  below. 


Beam 

Dwell  Time 
per  Beam 

Interferences 

Found 

ECCMs  Chemged 

1 

0.060 

ground 

mti .weight  changed 

During  subsequent  scans  the  MTI  weights  will  be  applied  to  CPIS,  ground  clutter 
will  be  less  visible  on  the  PPL  The  simulated  target  will  be  present  at  a  range  of  5 
miles. 


J-2.3  Expected  Results  if  Weather  is  Present 

If  there  is  weather  present  in  the  scan  region  during  this  or  any  subsequent  test,  the 
AI  display  will  indicate  that  weather,  as  well  as  ground  clutter,  h^^s  been  detected. 
Sample  display  lines  with  aijon  set  to  “no”  are  shown  below. 

Beam  Dvell  Time  Interferences  ECCMs  Changed 

per  Beam  Found 

1  0 . 054  weather 

ground 

When  ai_on  is  set  to  “yes”,  the  AI  display  will  indicate  that  polarization  has  changed 
and  the  MTI  is  applied  to  those  beams  containing  weather  interference.  The  MTI 
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weights  will  be  turned  on  to  null  the  doppler  spectrum  of  the  weather  and  ground 
sensed  during  the  ID  Active  Interference  process.  If  the  Adaptive  Controller  deems 
that  polarization  is  by  itself  sufficient  to  reduce  the  weather,  the  MTI  will  not  be 
enabled.  Sample  display  lines  are  shown  below. 

Beam  Dvell  Time  Interferences  ECCMs  Changed 

per  Beam  Found 

1  0.060  weather  tx.polar: zation  changed 

ground  mti. weight  changed 

During  subsequent  scans,  transmit  polarization  will  be  set  to  \’ertical  and  the  MTI 
weights  will  be  applied  to  CPIS.  The  weather  clutter  will  be  less  visible  on  the  PPI 
and  targets  should  become  more  discernible. 


J.3  Test  2;  WB  ASP  Jammer 

The  purpose  of  this  test  is  to  verify  that  the  IMRD  software  is  capable  of  identify¬ 
ing  a  wideband  asynchronous  pulsed  jammer  and  applying  the  appropriate  adaptive 
control,  sidelobe  blanking. 

J.3.1  Procedure 

1.  Turn  on  the  wideband  pulsed  jammer  via  the  HP2 11 7. 

2.  Use  the  Adaptive  Controller  Options  Menu  to  set  the  aijon  parameter  to  “no”. 

3.  Continue  the  Adaptive  Controller,  observing  the  PPI  and  AI  displays. 

4.  Use  the  Adaptive  Coiitroller  Option*-  to  set  the  ai.oi)  par--vmeter  to  “yes”. 

5.  Terminate  the  test  by  striking  any  key. 

6.  Note  the  following: 

(a)  the  cx>Dtents  of  the  PPI  display 

(b)  sources  of  interference  indk^ited  on  the  AI  display 

(c)  AI  decisions  indicated  on  the  AI  display. 
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J.3.2  Expected  Results 

During  the  scans  with  ai_on  set  to  “no”,  the  jammer  will  appear  in  the  mainlobe  and 
sidelobes  on  the  UPA-62  PPI  and  targets  (simulated  and  targets  of  opportunity)  will 
be  masked  by  jammer  interference. 

The  AI  display  will  indicate  that  a  wideband  pulsed  jammer  has  been  detected. 
Sample  display  lines  are  shown  below. 


Beam 

Dwell  Time 
per  Beau 

Interforences 

Found 

ECCMs  Changed 

1 

0.054 

ub..asp_sl_  jammer 

20 

0.054 

wb_asp_ml_  j  aunmer 

During  the  first  scan  with  ai_on  set  to  “yes”,  the  januner  will  appear  in  the  mainlobe 
and  sidelobes  on  the  UPA-62  PPI. 

The  AI  display  will  indicate  that  a  wideband  pulsed  jammer  has  been  detected  and 
that  sidelobe  blanking  is  enabled  for  those  beams  containing  a  pulsed  sidelobe  jammer. 

Beam 

Dwell  Time 
per  Beau 

Interferences 

Found 

ECCMs  Changed 

1 

0.054 

wb_aBp_8l_ j  ammer 

sidelobe.blanking  on 

20 

0.054 

wb_a8p_ml_ j  ammer 

During  subsequent  scans  after  ai.jon  has  been  set  to  “yes”,  there  will  be  no  evidence 
of  the  jammer  in  the  sidelobes  on  the  PPI  although  the  mainlobe  jammer  will  still  be 
visible.  Targets  will  appear  on  the  PPI. 


J.4  Test  3:  WB  CW  Jammer 

The  purpose  of  this  test  is  to  verify  that  the  IMRD  software  is  capable  of  identifying  a 
wideband  CW  jeimmer  and  applying  appropriate  adaptive  control,  sidelobe  cancelling. 
It  should  be  noted  that  presently  no  sidelobe  canceller  is  available.  The  Radar  Design 
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Parameters  are  initialized  with  the  cancellation  factor  for  the  sidelobe  canceller  se  to 
0  dB.  Therefore,  although  the  display  indicates  sidelobe  cancelling  will  be  enabled, 
no  sidelobe  cancelling  is  actually  performed. 

J.4.1  Procedure 

1.  Turn  on  the  wideband  CW  jammer  via  the  HP2117. 

2.  Continue  the  Adaptive  Contvoliei,  observing  the  PPI  and  AI  displays. 

3.  Terminate  the  test  by  striking  any  key. 

4.  Note  the  following: 

(a)  the  contents  of  the  PPI  display 

(b)  sources  of  interference  indicated  on  the  AI  display 

(c)  AI  decisions  indicated  on  the  AI  display. 

J.4.2  Expected  Results 

During  each  scan  the  jammer  will  appear  in  the  mainlobe  and  sidelobes  on  the  UPA  62 
PPI.  Targets  will  be  masked  by  the  jammer  interferences. 

The  AI  display  will  indicate  that  a  wideband  CW  jammer  has  been  detected  and 
that  the  sidelobe  canceller  is  enabled  for  all  beams  containing  a  CW  sidelobe  jammer. 
Sample  display  lines  are  shown  below. 


Beam 

Dwell  Time 

Interferences 

ECCMs  Changed 

per  Beam 

Found 

1 

0.054 

wb_cw_sl_jainii.  ,r 

sidelobe_cancelling  on 

20 

0.054 

wb_cw_ml_j ammer 

Sinc.e  there  is  no  sidelobe  cancaUer  available  and  the  jammer-to-noise  ratio  will  not 
be  decreased.  No  improverp'  nt  will  occur  on  the  PPI  other  than  due  to  dwell  time 
changes. 
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J.5  Ibst  4:  NB  CW  Jammer  and  Ground  Clutter 

The  purpose  of  this  test  is  to  verify  that  the  IMRD  software  is  capable  of  identifying 
a  narrowband  CW  jammer  and  applying  appropriate  adaptive  control  which  is  to 
change  frequency.  Ground  clutter  will  appear  after  the  jammer  is  removed.  It  will  be 
identified  by  the  Adaptive  Controller  and  removed  by  applying  MTI  weights. 


J.5.1  Procedure 

1.  Turn  on  the  narrowband  CW  jarmner  via  the  HP2117, 

2.  Use  the  Adaptive  Controller  Options  Menu  to  set  the  ai.on  ai.control  parameter 
to  “no”. 

3.  Continue  the  Adaptive  Controller,  observing  the  PPI  and  AI  displays. 

4.  Use  the  Adaptive  Controller  Options  Menu  to  set  the  ai^on  ai_control  parameter 
to  “yes”. 

5.  Instruct  the  IMRD  to  continue. 

6.  Terminate  the  test  by  striking  any  key. 

7.  Note  the  following: 

(a)  the  contents  of  the  PPI  display 

(b)  sources  of  interference  indicated  on  the  AI  display 

(c)  AI  decisions  indicated  on  the  AI  display. 

J.5. 2  Expected  Results 

During  the  scans  with  aijon  set  to  “no”,  the  jammer  will  appear  in  the  mainlobe  and 
sidelobes  on  the  UPA-62  PPI.  Targets  will  be  masked  by  the  jammer  interferences. 

The  AI  display  will  indicate  that  a  narrowband  CW  jc,mmer  has  been  detected. 
Sample  display  lines  are  shown  below. 

Beam  Dwell  Time  Interferences  ECCMs  Changed 

per  Beam  Found 

1  0.054  nb_cw_Bl_ jammer 


20 


0.054 


nb_cw_ml_j  ammer 
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During  the  the  first  scan  with  ai_on  set  to  “yes”,  the  jannmer  will  appear  in  the 
mainlobe  and  sidelobes  on  the  UPA-62  PPI  over  all  ranges.  Targets  will  remain 
masked  by  the  jammer  interferences. 

The  AI  display  will  indicate  that  a  narrowband  CW  jammer  has  been  detected  and 
that  a  frequency  change  is  enabled  for  every  beam  containing  a  narrowband  jammer 
declaration.  Sample  display  lines  are  shown  below. 


Beam 

Dwell  Time 
per  Beam 

Interferences 

Found 

ECCMs  Changed 

1 

0,054 

nb_cw_8l_j  aunmer 

frequency  changed 

20 

0.054 

nb_  cw.ml  _  j  junmer 

frequency  changed 

During  the  next  scan,  there  will  be  no  evidence  of  the  jammer  on  the  PPI  and  ground 
clutter  will  appear  in  some,  or  all,  of  the  beams.  MTI  will  be  selected  to  counter  that 
ground  clutter  where  it  appears.  Sample  display  lines  are  shown  below. 


Beam  Dwell  Time 
per  Beam 


Interferences 

Found 


ECCMs  Changed 


1  0.060 


ground 


mti .weight  chang 


During  subsequent  scans  the  MTI  weights  will  be  applied  to  CPI3  and  ground  clutter 
will  be  less  visible  on  the  PPI.  The  simulated  target  and  targets  of  opportunity  will 
appear  on  the  PPI  during  this  and  any  subsequent  scans. 


J.6  Test  5:  Two  NB  CW  Jammers  and  Ground  Clutter 

The  purpose  of  this  test  is  to  verify  that  the  IMRD  software  is  capable  of  identifying 
two  narrowband  CW  jammers  and  applying  appropriate  adaptive  control  which  is  to 
change  frequency. 

J.6,1  Procedure 

1.  Turn  on  two  narrowband  CW  jammers  via  the  HP2117. 

2.  Repeat  steps  2  through  8  of  Test  4. 
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J.6.2  Expected  Results 

The  results  should  be  the  same  as  for  Test  4  with  the  exception  that  a  mainlobe 
declaration  may  not  appear.  A  frequency  change  should  remove  both  jammers. 


J.7  Test  6:  NB  ASP  Jammer  and  Ground  C  lutter 

The  purpose  of  this  test  is  to  verify  that  the  IMRD  software  is  capable  of  identifying 
a  narrowband  pulsed  jammer  and  applying  appropriate  adaptive  control,  which  is  to 
change  frequency.  Ground  clutter  will  appear  after  the  jammer  is  removed.  It  will  be 
identified  by  the  Adaptive  Controller  and  removed  by  applying  MTI  weights. 

J,7-l  Procedure 

1.  Turn  on  the  narrowband  pulsed  jammer  via  the  HP2117. 

2.  Use  the  Adaptive  Controller  Options  Menu  to  set  the  ai-on  parameter  to  “no” . 
display 

3.  Continue  the  Adaptive  Controller,  observing  the  PPI  and  AI  displays 

4.  Use  the  Adaptive  Controller  Options  Menu  to  set  the  ai_on  parameter  to  “yes” . 

5.  Terminate  the  test  by  striking  any  key. 

6.  Note  the  following: 

(a)  the  contents  of  the  PPI  display 

(b)  sources  of  interference  indicated  on  the  AI  display 

(c)  AI  decisions  indicated  on  the  AI  display. 

J.7. 2  Expected  Results 

During  the  scans  with  ai-on  set  to  “no”,  the  jammer  will  appear  in  the  mainlobe  and 
sidelobes  on  the  UPA'62  PPI.  Targets  will  be  mewked  by  jammer  interferences. 

The  AI  display  will  indicate  that  a  narrowband  pulsed  jaimmer  has  been  detected. 
Sample  display  lines  are  shown  below. 

Beam  Dvell  Time  Interferences  ECCMs  Changed 

per  Beam  Foimd 
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1 


0.054 


nb_asp_8l_  j  aaunei: 


20  0.054 


nb_a.sp_inl_  j  aimn€>r 


During  the  first  scan  with  ai^n  set  to  “yes”,  the  janmier  will  appear  in  the  main- 
lobe  and  p.idelobes  on  the  UFA-62  PPL  Targets  will  remain  masked  by  the  jammer 
interferences. 

The  AI  display  will  indicate  that  a  narrowband  pulsed  j<immer  has  been  detected 
and  that  frequency  hopping  is  enabled  for  those  beams  where  narrowband  jamming 
occurs.  Sample  display  lines  are  shown  below. 


Bean  Dwell  Time 
per  Beam 

1  0.054 

20  0.054 


Interferences 

Found 

nb_asp_sl_ j  ammer 
nb.asp.ml. j  ammer 


ECCMs  Changed 


frequency  changed 


frequency  changed 


During  the  next  scan  ground  clutter  will  appear  on  the  PPL 

The  AI  display  will  indicate  that  ground  clutter  has;  been  detected  and  that  MTI 
weights  will  be  enabled  for  those  beams  containing  ground  clutter  during  the  next 


scan.  Sample 

display  lines  are 

shown  below. 

Beam 

Dwell  Time 
per  Beam 

Interferences 

Found 

ECCMs  Changed 

1 

0.060 

ground 

mti .weight  chaoiged 

During  subsequent  cr  aas  the  MTI  weights  will  be  applied  to  CPIS  and  groi;-..> 
will  be  less  visible  on  the  PPL 

Targets  will  appear  on  the  PPI  during  this  and  subsequent  scans. 


J.8  Test  7:  NB  ASF  Jammer,  Frequency  Change  Disabled 

The  purpose  of  this  test  is  to  verify  that  the  IMRD  software  is  capable  of  identifying 
a  narrowband  pulsed  jammer  and  applying  the  appripriate  ECCM.  In  this  case,  how- 
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ever,  the  most  appropriate  adaptive  control,  frer^uency  hopping,  is  \inavailable  and 
the  next  best  choice,  sidelobe  cancelling  will  be  selected.  The  test  will  be  conducted 
with  ai-on  set  to  “yes”. 


J.8.1  Procedure 

1.  Turn  on  the  narrowband  pulsed  jammer  via  the  HP2117. 

2.  Use  the  Adaptive  Controller  Options  Menu  to  remove  frequency.hopping  as  an 
available  ECCM.  This  is  an  AI  Contiol  parameters. 

3.  Continue  the  Adaptive  Controller,  observing  the  PPI  and  AI  displays. 

4.  Terminate  the  test  by  striking  any  key, 

5.  Note  the  tollowing: 

(a)  the  contents  of  the  PPI  display 

(b)  sources  of  interference  indicated  on  the  AI  display 

(c)  AI  decisions  indicated  on  the  AI  display. 


J.8.2  Expected  Results 

During  the  first  scsm  the  jammer  will  appear  in  the  mainlobe  and  sidelobes  on  the 
UPA-62  PPI.  Targets  will  be  masked  by  jammer  interferences. 

The  AI  display  will  indicate  that  a  narrowband  pulsed  jammer  has  been  detected  and 
that  sidelobe  blanking  is  enabled  for  those  beams  in  which  pulsed  sidelobe  jamming 
occurs.  Sample  display  lines  are  shown  below. 


Beaa  Dv«ll  Tiae 
per  Bean 

1  0.400 

20  0 . 400 


Interferences 

Found 

nb_asp_sl_ j  anaer 

nb.asp.Bl. j  amaer 


ECCHs  Changed 

sidelobe.blanking  on 


During  subequmt  scans  ground  clutter  will  appear  ot<  the  PPI  and  will  be  countered 
as  in  Test  1. 
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J.9  Test  8;  Quality  Options 

The  purpose  of  this  test  is  to  verify  that  the  IMRD  software  is  capable  of  incorporating 
user- specified  Priority  Zones  and  Quality  Options  into  decisions  for  allocating  dwell 
time. 

J.9.1  Procedure 

1.  Use  the  Adaptive  Controller  Options  Menu  to  edit  the  Priority  Zones  table, 
producing  the  following: 

(a)  a  high  threat  region  in  beams  1-8  (azimuth  singles  -  22.5  to  -13.5) 

(b)  a  medium  threat  region  in  beams  9-16  (azimuth  angles  -13.5  to  -4.5) 

(c)  a  low  threat  region  in  beams  17-24  (azimuth  angles  -4.5  to  4.5) 

(d)  a  friendly  region  in  beams  25-32  (azimuth  angles  4.5  to  13.5) 

(e)  an  unoccupied  region  in  beams  33-40  (azimuth  angles  13.5  to  22.5) 

See  Figure  J-1 

2.  Use  the  Ad.  ‘  Controller  Options  Menu  to  exanune  the  contents  of  the 
Quality  Opt  .ible. 

3.  Continue  the  Adaptive  Controller,  observing  the  PPI  and  AI  displays. 

4.  Turn  on  a  wideband  CW  jammer  at  20  dB  attenuation  via  the  HP2117. 

5.  Change  the  jammer  to  0  dB  attenuation  and  continue. 

6.  Terminate  the  test  by  striking  any  key. 

7.  Note  the  following: 

(a)  the  contents  of  the  PPI  display 

(b)  sources  of  interference  indicated  on  the  AI  display 

(c)  the  quality  option  selected  for  each  scan 

J.9. 2  Expected  Results 

With  the  jammer  >11  the  signal-to-interference  ratio  is  sufficient  that  all  regions  can 
reach  the  highest  probability  of  detection.  The  best  Quality  Option  (1)  vi  selected 
and  dwell  time  is  allocated  equally  over  all  beams. 

While  the  first  jammer  (medium  jammer  power)  ic  operating  there  will  be  insufficent 
time  to  acheive  the  highest  probability  of  detection  in  all  zones.  Thus  the  higher 
threat  zones  will  receive  more  energy  than  the  lower  ones. 


IMRD  Test  Cases 
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Hi|h 

X  iaiwiicr 


While  the  second  jammer  (high  power)  is  operating,  the  lowest  Quality  Option  (9) 
is  most  likely  to  be  selected,  allocating  all  dwell  time  to  the  highest  priority  region, 
besmis  1  through  8. 
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Force  Command,  Control,  Communications  and  Intelligence  (C  I)  activities 
for  all  Air  Force  platforms.  It  also  executes  selected  acquisition  programs 
in  several  areas  of  expertise.  Technical  and  engineering  support  within 
areas  of  competence  is  provided  to  ESD  Program  Offices  (POs)  and  other 
ESD  elements  to  perform  effective  acquisition  of  C"!  systems.  Ifi  addition, 
Rome  Laboratory's  technology  supports  other  AFSC  Product  Divisions,  the 
Air  Force  user  community,  and  other  DOD  and  non-DQD  agencies.  Rome 
Laboratory  maintains  technical  competence  and  research  programs  in  areas 
including,  but  not  limited  to,  communications,  command  and  control,  battle 
management,  intelligence  information  processing,  computational  sciences 
and  software  producibility,  wide  area  surveillance/sensors,  signal  proces¬ 
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